Backup

Backup або резервне копіювання — це процес створення додаткової копії даних, файлів, баз даних, конфігурацій або систем, щоб їх можна було відновити після втрати, помилки, збою, атаки, пошкодження, випадкового видалення або аварії.

Backup потрібен не тільки великим компаніям. Він важливий для особистих файлів, сайтів, застосунків, баз даних, серверів, хмарних систем, телефонів, ноутбуків, DevOps-процесів, SaaS-платформ і будь-яких даних, які шкода втратити.

Основна ідея: backup — це запасний шлях назад, коли основні дані зникли, зламалися або стали непридатними.

Цікавий факт

Найпоширеніша помилка з backup — думати, що він існує, поки не спробували restore. Файл може бути скопійований, архів може лежати в хмарі, snapshot може створюватися щодня, але справжній backup існує тільки тоді, коли з нього реально можна відновити дані.

Тому в професійних системах важлива не лише фраза “ми робимо backup”, а питання: “коли востаннє ми перевіряли restore?”

Найлюдяніший факт: backup — це як парасолька. Найбільше він потрібен саме тоді, коли вже пізно шукати, де вона лежить.

Загальний опис

Backup використовується для захисту від:

випадкового видалення;
помилки користувача;
помилки адміністратора;
збою диска;
пошкодження бази даних;
невдалого оновлення;
ransomware;
атаки;
пожежі або крадіжки обладнання;
помилки deployment;
хмарного збою;
втрати ноутбука;
пошкодження файлової системи;
помилкової міграції;
software bug;
human error.

Backup може охоплювати:

файли;
бази даних;
конфігурації;
virtual machines;
containers volumes;
object storage;
emails;
documents;
source code;
media files;
server images;
Kubernetes resources;
secrets;
logs;
application state.

Перевага: backup зменшує ціну помилки. Якщо щось зламалося, команда має шанс повернутися до робочого стану.

Backup і Restore

Backup — це створення резервної копії. Restore — це відновлення з резервної копії.

Ці два поняття нерозривні.

Backup без restore-перевірки = припущення
Backup із перевіреним restore = реальний захист

Restore може бути:

повним;
частковим;
file-level;
database-level;
point-in-time;
bare-metal;
application-level;
disaster recovery restore.

Критично: backup, який неможливо відновити, не захищає дані. Він лише створює ілюзію безпеки.

3-2-1 Backup Rule

3-2-1 rule — популярне правило резервного копіювання.

Воно означає:

3 копії даних;
2 різні типи носіїв або сховищ;
1 копія поза основною локацією.

Приклад:

1 основна копія на сервері
1 backup на окремому storage
1 backup у хмарі або іншому дата-центрі

Проста аналогія: не тримайте всі ключі від дому в одному рюкзаку.

Full Backup

Full backup — повна копія всіх вибраних даних.

Переваги:

простіше відновлення;
одна повна точка копії;
менше залежностей між backup-файлами;
зручно для базової копії.

Недоліки:

займає більше місця;
довше створюється;
може створювати більше навантаження;
дорожчий у storage.

Практична роль: full backup — це найпростіша для розуміння модель: “ось повна копія всього на цей момент”.

Incremental Backup

Incremental backup зберігає тільки зміни після попереднього backup.

Приклад:

Неділя: full backup
Понеділок: зміни за понеділок
Вівторок: зміни після понеділка
Середа: зміни після вівторка

Переваги:

економить місце;
швидше створюється;
менше навантаження.

Недоліки:

restore може бути складнішим;
потрібен ланцюжок backup-ів;
пошкодження одного елемента може вплинути на відновлення.

Важливо: incremental backup економить ресурси, але потребує дисципліни й перевірки restore-ланцюжка.

Differential Backup

Differential backup зберігає зміни після останнього full backup.

Приклад:

Неділя: full backup
Понеділок: зміни після неділі
Вівторок: усі зміни після неділі
Середа: усі зміни після неділі

Переваги:

простіший restore, ніж у багатьох incremental-схемах;
потрібно full backup + останній differential;
менше складності в ланцюжку.

Недоліки:

differential backup з часом росте;
займає більше місця, ніж incremental;
потребує регулярних full backup.

Практична роль: differential backup — компроміс між простотою full backup і економією incremental backup.

Snapshot

Snapshot — знімок стану системи, диска, volume, бази даних або storage на певний момент.

Snapshots використовують для:

швидкого rollback;
короткострокового захисту;
перед оновленням;
перед міграцією;
cloud volumes;
virtual machines;
development environments;
testing.

Але snapshot не завжди дорівнює повноцінному backup.

Важливо: snapshot часто залежить від основного storage. Якщо зникне весь storage або акаунт, snapshot може зникнути разом із ним.

Database Backup

Database backup — резервне копіювання бази даних.

Він може бути:

logical backup;
physical backup;
dump;
snapshot;
continuous backup;
point-in-time recovery;
replication-based backup у частині сценаріїв.

Для баз даних важливо враховувати:

consistency;
transactions;
write-ahead logs;
schema;
indexes;
roles;
extensions;
stored procedures;
large objects;
permissions;
restore time;
data size;
application compatibility.

Критично: просто скопіювати файли бази даних під час її роботи не завжди безпечно. Потрібен database-aware backup.

Logical Backup

Logical backup зберігає дані у вигляді логічного представлення: SQL, dump, JSON, CSV або інший формат.

Приклади:

`pg_dump` для PostgreSQL;
`mysqldump` для MySQL/MariaDB;
export collections;
SQL dump;
schema export.

Переваги:

зручно переносити між системами;
можна відновлювати частково;
легко читати структуру;
корисно для migration;
часто незалежніше від storage.

Недоліки:

повільніше для великих баз;
не завжди підходить для huge production;
може вимагати downtime або special consistency mode;
restore може тривати довго.

Практична роль: logical backup добре підходить для малих і середніх баз, міграцій, dev-копій і вибіркового відновлення.

Physical Backup

Physical backup копіює фізичні файли бази або storage-level дані у підтримуваний спосіб.

Переваги:

швидше для великих баз;
краще підходить для production-scale;
може підтримувати point-in-time recovery;
зберігає фізичну структуру.

Недоліки:

сильніше прив’язаний до версії й storage;
складніше переносити;
потребує правильного інструменту;
restore може вимагати сумісного середовища.

Важливо: physical backup потрібно робити інструментами, які розуміють базу даних або storage consistency.

Point-in-Time Recovery

Point-in-Time Recovery або PITR — відновлення системи до конкретного моменту часу.

Наприклад:

Відновити базу на стан 2026-05-09 13:42:10,
за хвилину до випадкового DELETE.

PITR корисний для:

випадкового видалення;
невдалої міграції;
помилки застосунку;
data corruption;
security incident;
фінансових систем;
production database.

Практична роль: PITR дозволяє не просто відновити “вчорашній backup”, а повернутися до точного моменту перед проблемою.

RPO

RPO або Recovery Point Objective — скільки даних бізнес готовий втратити у часі.

Приклади:

RPO	Що означає
24 години	можна втратити дані за останню добу
1 година	можна втратити максимум годину змін
5 хвилин	потрібні дуже часті backup або журналювання
майже 0	потрібна складна high availability і replication-стратегія

Важливо: RPO — це бізнес-рішення, а не тільки технічне. Чим менший RPO, тим дорожча й складніша система.

RTO

RTO або Recovery Time Objective — за який час систему потрібно відновити після збою.

Приклади:

RTO	Що означає
2 дні	бізнес може чекати довге ручне відновлення
4 години	потрібен готовий restore-процес
30 хвилин	потрібна автоматизація й тренування
кілька хвилин	потрібна high availability і швидкий failover

Проста різниця: RPO — скільки даних можна втратити, RTO — скільки часу можна бути недоступним.

Backup Strategy

Backup strategy — план, який визначає, що, як, де, коли й навіщо копіюється.

Стратегія має відповідати на питання:

які дані критичні;
як часто створюється backup;
де він зберігається;
хто має доступ;
як довго зберігається;
чи є encryption;
як перевіряється restore;
які RPO і RTO;
що робити при ransomware;
як відновлювати application;
як відновлювати database;
як відновлювати configuration;
хто відповідальний;
як документований процес.

Головна думка: backup strategy — це не “раз на день щось кудись копіюємо”, а продуманий план виживання даних.

Offsite Backup

Offsite backup — копія, що зберігається поза основною локацією.

Це може бути:

інший дата-центр;
хмарне сховище;
інший регіон;
фізичний носій в іншому місці;
окремий акаунт;
окрема організаційна зона.

Offsite backup захищає від:

пожежі;
крадіжки;
знищення обладнання;
локального ransomware;
втрати дата-центру;
помилки в одному cloud account;
аварії в одній локації.

Важливо: backup на тому самому сервері — це краще, ніж нічого, але він не захищає від втрати всього сервера.

Immutable Backup

Immutable backup — backup, який не можна змінити або видалити протягом заданого періоду.

Він корисний проти:

ransomware;
помилкового видалення;
compromised admin account;
malicious insider;
destructive scripts;
supply chain attacks.

Immutable backup може використовувати:

object lock;
write once read many;
retention lock;
append-only storage;
restricted deletion policies.

Критично: якщо ransomware може видалити або зашифрувати backup, backup не є достатнім захистом.

Backup Encryption

Backup encryption — шифрування резервних копій.

Шифрування потрібне для захисту:

персональних даних;
фінансових даних;
медичних даних;
credentials;
source code;
бізнес-документів;
database dumps;
cloud archives;
external drives.

Потрібно контролювати:

encryption keys;
key rotation;
доступ до ключів;
recovery ключів;
хто може decrypt;
де зберігаються keys;
чи не лежить key поруч із backup.

Важливо: encrypted backup без доступного ключа не відновити. Ключі потрібно захищати, але не втрачати.

Backup Retention

Retention — політика зберігання backup-ів.

Вона визначає:

скільки backup-ів зберігати;
як довго;
які backup-и архівувати;
які видаляти;
які потрібні для compliance;
які потрібні для rollback;
скільки коштує storage;
чи є legal requirements.

Приклад retention:

Hourly backups: 24 години
Daily backups: 30 днів
Weekly backups: 12 тижнів
Monthly backups: 12 місяців
Yearly backups: 7 років

Практична роль: retention допомагає не зберігати все вічно, але й не видалити потрібну точку відновлення занадто рано.

Backup Testing

Backup testing — перевірка, що backup можна відновити.

Тестування може включати:

restore на test environment;
перевірку checksum;
запуск application після restore;
перевірку database integrity;
перевірку permissions;
перевірку файлів;
вимірювання restore time;
симуляцію disaster recovery;
перевірку documentation;
перевірку доступу до ключів encryption.

Критично: перший restore не має відбуватися під час справжньої аварії.

Disaster Recovery

Disaster Recovery або DR — ширший план відновлення після серйозної аварії.

DR включає:

backup;
restore procedures;
failover;
alternate infrastructure;
communication plan;
incident roles;
runbooks;
recovery priorities;
RPO;
RTO;
dependency map;
testing;
post-incident review.

Backup — це частина DR, але не весь DR.

Проста різниця: backup — це копія даних, disaster recovery — це план повернення бізнесу до роботи.

High Availability і Backup

High Availability або HA зменшує downtime, але не замінює backup.

HA може захистити від:

падіння сервера;
недоступності одного вузла;
частини infrastructure failures;
необхідності ручного перезапуску.

Але HA не завжди захищає від:

випадкового DELETE;
ransomware;
логічної помилки;
data corruption;
поганої міграції;
компрометації admin account;
помилки application.

Критично: реплікація й high availability — не backup. Якщо помилка потрапила на primary, вона може швидко потрапити й на replica.

RAID і Backup

RAID допомагає пережити відмову диска, але не є backup.

RAID може допомогти при:

disk failure;
локальній hardware redundancy;
продовженні роботи storage.

RAID не захищає від:

випадкового видалення;
ransomware;
пожежі;
крадіжки сервера;
помилки застосунку;
пошкодження даних;
неправильного deployment;
видалення таблиці в базі.

Важливо: RAID підвищує доступність storage, але backup захищає історичні копії даних.

Cloud Backup

Cloud backup — резервна копія, що зберігається в хмарному сховищі або керованому backup-сервісі.

Переваги:

offsite storage;
масштабованість;
automation;
lifecycle policies;
encryption;
geo-replication у частині сценаріїв;
object lock;
managed retention;
зручний доступ.

Ризики:

неправильні IAM permissions;
vendor lock-in;
витрати на storage і restore;
залежність від інтернету;
помилка cloud account;
неправильний region;
відсутність restore testing.

Практична роль: cloud backup зручний для offsite-копій, але його теж потрібно захищати, шифрувати й тестувати.

Server Backup

Server backup охоплює дані й конфігурацію сервера.

Може включати:

application files;
configuration;
system packages list;
databases;
logs;
SSL certificates;
cron jobs;
user data;
firewall rules;
service configs;
environment files;
deployment scripts.

Але часто краще відновлювати сервер через infrastructure as code, а backup робити для даних і важливої конфігурації.

Практична порада: якщо сервер можна швидко відтворити через automation, backup має фокусуватися на даних, secrets і state.

Application Backup

Application backup має враховувати все, що потрібно для відновлення застосунку.

Це може бути:

database;
uploaded files;
configuration;
secrets;
object storage;
search index у частині сценаріїв;
message queue state у частині сценаріїв;
user-generated content;
scheduled jobs;
deployment manifests;
application version;
migrations;
feature flags.

Практична роль: application backup — це не тільки база даних. Якщо користувацькі файли зберігаються окремо, їх теж потрібно копіювати.

Configuration Backup

Конфігурації часто забувають копіювати, хоча без них система може не запуститися.

Важливі конфігурації:

web server config;
environment variables;
deployment manifests;
DNS records;
firewall rules;
IAM policies;
Kubernetes YAML;
Terraform state;
CI/CD secrets references;
cron schedules;
application settings;
database roles.

Важливо: дані без конфігурації можуть бути як двигун без ключа: усе є, але система не стартує.

Personal Backup

Особистий backup потрібен для:

фото;
документів;
навчальних файлів;
проєктів;
паролів у password manager export;
телефонних даних;
ноутбука;
notes;
contacts;
важливих листів;
творчих робіт.

Добра особиста стратегія:

локальна копія;
cloud copy;
зовнішній диск;
password manager;
encryption;
регулярна перевірка;
не тримати всі копії в одному місці.

Найлюдяніший сенс: backup особистих фото й документів потрібен не для “айтішності”, а щоб не втратити роки життя через один зламаний диск.

Mobile Backup

Mobile backup зберігає дані телефону або планшета.

Може включати:

photos;
contacts;
app data;
messages;
settings;
documents;
notes;
device configuration;
health data у частині сценаріїв.

Ризики:

backup без encryption;
забутий акаунт;
переповнене cloud storage;
неповний backup;
відсутність restore-перевірки;
втрата 2FA recovery codes.

Практична порада: окремо зберігайте recovery codes для 2FA, бо після втрати телефону саме вони можуть бути важливішими за сам телефон.

Backup у DevOps

У DevOps backup має бути частиною production-процесу.

Потрібно враховувати:

automated backups;
infrastructure as code;
database dumps;
object storage backups;
secret recovery;
restore runbooks;
monitoring backup jobs;
alerting on failed backups;
disaster recovery drills;
retention policy;
environment restoration;
CI/CD artifact backups;
rollback strategy.

Практична роль: backup job має бути не “десь у cron”, а контрольованою частиною operations із логами, alert-ами й відповідальними.

Backup у Kubernetes

У Kubernetes потрібно думати не лише про manifests, а й про persistent data.

Backup може включати:

etcd backup;
PersistentVolume data;
database backup;
namespaces;
custom resources;
secrets;
config maps;
Helm releases;
ingress configs;
storage class details.

Важливо: Kubernetes deployment YAML можна відтворити з Git, але дані в PersistentVolumes потрібно backup-ити окремо.

Backup у Docker

У Docker важливо копіювати не сам container, а state.

Зазвичай потрібно backup-ити:

named volumes;
bind mount directories;
database dumps;
configuration files;
compose files;
secrets;
uploaded files;
registry images у частині сценаріїв.

Важливо: якщо дані жили тільки в writable layer контейнера, видалення контейнера може означати втрату даних.

WordPress Backup

WordPress backup має включати:

database;
`wp-content/uploads`;
themes;
plugins;
`wp-config.php`;
custom code;
WooCommerce orders;
media library;
redirects;
settings;
backup plugin configuration.

Критично: WordPress backup без бази даних або без uploads — неповний. Сайт може відновитися без контенту або без медіа.

PostgreSQL Backup

Для PostgreSQL часто використовують:

`pg_dump`;
`pg_restore`;
`pg_basebackup`;
WAL archiving;
point-in-time recovery;
physical backup tools;
managed cloud backups.

Приклад logical backup:

pg_dump -Fc -d appdb -f appdb.dump

Приклад restore:

createdb appdb_restore
pg_restore -d appdb_restore appdb.dump

Важливо: для великих production-баз одного `pg_dump` може бути замало. Часто потрібні physical backups і WAL archiving.

MySQL і MariaDB Backup

Для MySQL і MariaDB backup може включати:

`mysqldump`;
physical backup tools;
binary logs;
replication;
snapshots;
managed backups;
point-in-time recovery у відповідних сценаріях.

Приклад:

mysqldump --single-transaction appdb > appdb.sql

Практична порада: для InnoDB важливо використовувати consistent backup-підхід, щоб не отримати пошкоджену або неповну копію.

Backup Monitoring

Backup потрібно моніторити.

Важливі перевірки:

чи backup job успішно завершився;
скільки тривав backup;
розмір backup;
чи не став розмір раптово нульовим;
чи створився файл;
чи пройшла перевірка integrity;
чи доступний storage;
чи не закінчується місце;
чи не минув термін ключів;
чи не порушена retention policy;
чи пройшов test restore.

Критично: мовчазний failed backup — одна з найнебезпечніших проблем. Команда може місяцями думати, що дані захищені.

Backup і Ransomware

Ransomware може шифрувати або видаляти дані, а іноді й backup-и.

Захист включає:

immutable backups;
offline backups;
separate credentials;
least privilege;
backup account isolation;
monitoring deletion attempts;
object lock;
MFA для backup systems;
regular restore tests;
incident response plan;
не монтувати backup storage постійно з write access.

Критично: backup має бути захищений від тієї ж атаки, яка знищує основні дані.

Backup і Privacy

Backup може містити персональні й чутливі дані.

Потрібно враховувати:

encryption;
access control;
retention;
data deletion requests;
anonymization у частині сценаріїв;
backups у різних регіонах;
logs із персональними даними;
legal requirements;
хто може restore;
хто може download backup;
audit logs доступу до backup.

Важливо: backup — це теж копія персональних даних. Privacy rules не зникають лише тому, що дані лежать в архіві.

Backup і Security

Безпека backup включає:

encryption at rest;
encryption in transit;
access control;
MFA;
audit logs;
key management;
immutable storage;
separate admin accounts;
least privilege;
vulnerability management;
secure deletion;
network restrictions;
restore approval;
secret handling.

Критично: backup часто містить усе найцінніше. Якщо його вкрадуть, це може бути не менш небезпечно, ніж злам production.

Backup і Secrets

Secrets потрібно backup-ити обережно.

До secrets належать:

API keys;
database passwords;
private keys;
certificates;
encryption keys;
OAuth credentials;
cloud credentials;
recovery codes.

Небезпека:

backup без secrets може не дозволити відновити систему;
backup із secrets може бути дуже чутливим;
втрата encryption key може зробити backup марним;
витік backup із secrets може дати доступ до production.

Практична порада: secrets мають бути збережені так, щоб їх можна було відновити, але не можна було легко викрасти.

Air-Gapped Backup

Air-gapped backup — копія, фізично або логічно відокремлена від основної мережі.

Приклади:

offline external drive;
tape backup;
isolated storage;
disconnected archive;
restricted offline vault.

Переваги:

сильний захист від ransomware;
менше ризику remote deletion;
корисно для critical data.

Недоліки:

складніше автоматизувати;
повільніший restore;
потребує фізичної дисципліни;
ризик застарівання носіїв;
складніше тестувати часто.

Практична роль: air-gapped backup — це остання лінія оборони, коли онлайн-системи скомпрометовані.

Backup Media

Носії для backup можуть бути різними:

external HDD;
external SSD;
NAS;
cloud object storage;
tape;
optical media у рідкісних сценаріях;
remote server;
backup appliance;
managed backup service.

Критерії вибору:

вартість;
швидкість;
довговічність;
capacity;
encryption;
portability;
restore speed;
physical safety;
automation;
compatibility.

Важливо: носій backup теж може зламатися. Саме тому потрібні кілька копій і перевірка.

Backup Compression

Compression зменшує розмір backup.

Переваги:

економія storage;
швидша передача в частині сценаріїв;
менші витрати;
зручніші архіви.

Недоліки:

CPU overhead;
повільніше створення або restore;
ризик пошкодження archive;
не всі дані добре стискаються;
encrypted data часто погано стискається.

Практична роль: compression корисна для текстових dumps, logs і документів, але менш ефективна для вже стиснених фото, відео або encrypted archives.

Backup Deduplication

Deduplication усуває повторювані блоки або файли в backup.

Переваги:

менше storage;
швидші backup-и після першого;
економія costs;
ефективність для схожих datasets.

Недоліки:

складніша система;
restore залежить від metadata;
може бути vendor-specific;
потребує перевірки integrity.

Практична роль: deduplication особливо корисна, коли щоденні backup-и містять багато однакових даних.

Backup Verification

Verification перевіряє, що backup не пошкоджений.

Може включати:

checksum;
archive validation;
database consistency check;
restore dry run;
file count comparison;
sample read;
cryptographic hash;
application smoke test after restore.

Важливо: verification не замінює повний restore test, але допомагає раніше виявити пошкоджені backup-и.

Backup Runbook

Runbook — покрокова інструкція для backup і restore.

Він має містити:

де лежать backup-и;
як отримати доступ;
які credentials потрібні;
як розшифрувати;
як відновити database;
як відновити files;
як перевірити application;
кого повідомити;
як оцінити RPO/RTO;
як діяти при failed restore;
як перевірити integrity;
як документувати incident.

Практична роль: runbook потрібен, щоб під час аварії не згадувати процес із голови в стресі.

Переваги Backup

Основні переваги:

захист від втрати даних;
можливість restore;
менший ризик простою;
захист від людських помилок;
захист від ransomware у правильній схемі;
підтримка compliance;
можливість rollback;
безпечніші migration і update;
спокійніший DevOps;
відновлення після hardware failure;
захист бізнес-континуїтету;
можливість архівування.

Головна перевага: backup дає шанс виправити катастрофічну помилку без повної втрати даних.

Ризики і обмеження Backup

Backup має обмеження.

Можливі проблеми:

backup не створився;
backup пошкоджений;
restore не тестувався;
backup містить застарілі дані;
backup не включає важливі файли;
backup зберігається поруч із production;
backup не зашифрований;
encryption key втрачено;
backup видалено ransomware;
restore триває занадто довго;
retention занадто короткий;
backup містить приватні дані без контролю;
backup не відповідає compliance;
ніхто не знає, як відновлювати.

Небезпека: backup може створити фальшиве відчуття безпеки, якщо ніхто не перевіряє, що з нього реально можна відновитися.

Коли Backup обов’язковий

Backup обов’язковий, якщо є:

production database;
користувацькі файли;
фінансові дані;
персональні дані;
бізнес-документи;
source code;
сайт або магазин;
конфігурації серверів;
SaaS-продукт;
медичні або юридичні записи;
навчальні або творчі роботи;
дані, які неможливо легко відтворити.

Критично: якщо дані неможливо швидко відтворити вручну, вони потребують backup.

Коли Backup можна спростити

Backup можна спростити, якщо:

дані тимчасові;
систему легко відтворити;
немає production;
немає користувацьких даних;
це disposable environment;
дані генеруються автоматично;
є source of truth в іншому місці.

Але навіть тоді потрібно розуміти:

що саме можна втратити;
за який час це можна відновити;
чи є приховані важливі файли;
чи не зберігаються secrets;
чи є документація.

Важливо: “це неважливо” має бути усвідомленим рішенням, а не випадковим відкриттям після аварії.

Хороші практики Backup

Рекомендовано:

використовувати 3-2-1 rule;
мати offsite backup;
тестувати restore;
шифрувати backup-и;
контролювати доступ;
мати retention policy;
моніторити backup jobs;
налаштувати alert-и на failed backups;
документувати runbook;
перевіряти RPO і RTO;
використовувати immutable backup для critical data;
не покладатися лише на RAID або replication;
робити database-aware backups;
зберігати backup окремо від production credentials;
регулярно проводити disaster recovery drills;
перевіряти, що backup включає всі потрібні дані.

Головне правило: backup має бути автоматичним, захищеним, перевіреним і відновлюваним.

Типові помилки початківців

Поширені помилки:

думати, що RAID — це backup;
думати, що replica — це backup;
не тестувати restore;
зберігати backup на тому самому сервері;
не backup-ити uploads;
backup-ити тільки файли, але не database;
backup-ити database, але не configuration;
не шифрувати backup;
втратити encryption key;
не мати retention policy;
не помічати failed backup jobs;
робити manual backup без графіка;
не мати offsite-копії;
не враховувати ransomware;
не документувати restore steps.

Небезпека: найгірший момент дізнатися, що backup неповний, — це момент, коли основні дані вже втрачені.

Цікаві факти про Backup

Backup без restore-перевірки — це лише надія.
Реплікація може швидко скопіювати помилку на replica, тому вона не замінює backup.
Snapshot зручний, але не завжди є повноцінною резервною копією.
Immutable backup став особливо важливим через ransomware.
RPO і RTO допомагають говорити про backup мовою бізнесу, а не тільки техніки.
Найцінніші дані часто не в коді, а в базі даних і user uploads.
Backup може бути небезпечним, якщо його вкрали: він часто містить усю систему.
Хороший restore runbook може зекономити години паніки.
Найкращий backup-план той, який уже перевіряли в спокійний день.
Старий external drive у шухляді — не стратегія backup, якщо ніхто не знає, чи він читається.

Найлюдяніший факт: backup — це не про песимізм. Це про повагу до своєї роботи, часу й даних інших людей.

Приклади сценаріїв використання

Сайт малого бізнесу

Backup має включати database, uploads, тему, plugins, конфігурацію й SSL-related settings. Restore потрібно тестувати на staging.

SaaS-застосунок

Backup охоплює production database, object storage, configuration, secrets recovery, audit logs і disaster recovery plan.

Особистий ноутбук

Важливі документи, фото, навчальні роботи й проєкти зберігаються локально, на external drive і в хмарі.

PostgreSQL production

Використовуються physical backups, WAL archiving, PITR, регулярні restore drills і monitoring backup jobs.

Захист від ransomware

Компанія використовує immutable backup, offsite-копію, MFA, ізольовані backup credentials і регулярні recovery tests.

Підказка: найкращий спосіб перевірити backup-стратегію — уявити, що production зник просто зараз, і чесно пройти всі кроки відновлення.

Приклад простого backup-плану

Що копіюємо:
- PostgreSQL database
- uploaded files
- application configuration
- deployment manifests

Як часто:
- database: щогодини incremental/WAL, щодня full
- uploads: щодня
- configuration: після кожної зміни

Де зберігаємо:
- primary backup storage
- offsite cloud storage
- immutable monthly archive

Retention:
- hourly: 48 годин
- daily: 30 днів
- weekly: 12 тижнів
- monthly: 12 місяців

Перевірка:
- test restore щомісяця
- alert on failed backup
- quarterly disaster recovery drill

Практична роль: такий план уже відповідає на головні питання: що, коли, де, як довго й як перевіряємо.

Приклад checklist для Backup

Чи знаємо, які дані критичні?
Чи є 3 копії?
Чи є offsite backup?
Чи є immutable або offline copy?
Чи backup зашифрований?
Чи ключі шифрування доступні для recovery?
Чи є retention policy?
Чи моніторяться backup jobs?
Чи є alert на failed backup?
Чи тестували restore?
Чи відомий RPO?
Чи відомий RTO?
Чи є runbook?
Чи backup включає database, files і configuration?
Чи захищений backup від ransomware?

Практична роль: checklist допомагає швидко побачити слабкі місця backup-стратегії.

Приклад команд для простого file backup

tar -czf site-files-$(date +%F).tar.gz /var/www/site
sha256sum site-files-$(date +%F).tar.gz > site-files-$(date +%F).sha256

Важливо: це лише простий приклад архівування файлів. Для production потрібні encryption, offsite copy, monitoring і restore test.

Джерела

Практики data backup і disaster recovery.
Матеріали щодо 3-2-1 backup rule, RPO, RTO і restore testing.
Документація баз даних щодо logical backup, physical backup, WAL, binary logs і point-in-time recovery.
Практики DevOps щодо backup automation, monitoring, runbooks, CI/CD, infrastructure as code і disaster recovery drills.
Матеріали щодо cloud backup, immutable backup, object lock, ransomware protection, backup encryption і access control.
Практики privacy, compliance, retention policy, audit і security incident response.

Висновок

Backup — це фундаментальний механізм захисту даних від втрати, помилок, атак і аварій. Він потрібен для особистих файлів, застосунків, баз даних, серверів, сайтів, SaaS-систем, хмарної інфраструктури й бізнес-процесів.

Хороший backup — це не просто копія. Він має бути регулярним, автоматичним, зашифрованим, захищеним, збереженим offsite, контрольованим retention policy, перевіреним через restore і задокументованим у runbook. Найважливіше: backup має реально відновлюватися.

Головна думка: backup — це не файл у архіві. Це здатність повернути дані й роботу системи тоді, коли щось пішло не так.

Цікавий факт

Загальний опис

Backup і Restore

3-2-1 Backup Rule

Full Backup

Incremental Backup

Differential Backup

Snapshot

Database Backup

Logical Backup

Physical Backup

Point-in-Time Recovery

RPO

RTO

Backup Strategy

Offsite Backup

Immutable Backup

Backup Encryption

Backup Retention

Backup Testing

Disaster Recovery

High Availability і Backup

RAID і Backup

Cloud Backup

Server Backup

Application Backup

Configuration Backup

Personal Backup

Mobile Backup

Backup у DevOps

Backup у Kubernetes

Backup у Docker

WordPress Backup

PostgreSQL Backup

MySQL і MariaDB Backup

Backup Monitoring

Backup і Ransomware

Backup і Privacy

Backup і Security

Backup і Secrets

Air-Gapped Backup

Backup Media

Backup Compression

Backup Deduplication

Backup Verification

Backup Runbook

Переваги Backup

Ризики і обмеження Backup

Коли Backup обов’язковий

Коли Backup можна спростити

Хороші практики Backup

Типові помилки початківців

Цікаві факти про Backup

Приклади сценаріїв використання

Сайт малого бізнесу

SaaS-застосунок

Особистий ноутбук

PostgreSQL production

Захист від ransomware

Приклад простого backup-плану

Приклад checklist для Backup

Приклад команд для простого file backup

Джерела

Висновок

Див. також

Тематичні мітки