Backup

Недоліки:

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

Висновок

Backup Deduplication

Чи є собою retention policy?;

- application configuration

Differential 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;

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

Найлюдяніший факт: backup — це як парасолька.; Чим менший RPO, тим дорожча й складніша платформа.; Сайт має змогу відновитися без контенту або без медіа.; Часто потрібні physical backups і WAL archiving.; - weekly: 12 тижнів Immutable backup має змогу використовувати: Недоліки:

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

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

1 backup у хмарі або іншому дата-центрі

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

checksum;
archive validation;
database consistency check;
restore dry run;
file count comparison;
sample read;
cryptographic hash;
application smoke test after restore.; істотно: це лише простий приклад архівування файлів.;== RPO ==

думати, що 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.;

restore має змогу бути складнішим;
потрібен ланцюжок backup-ів;
пошкодження одного елемента має змогу вплинути на відновлення.; * Найкращий backup-план той, який уже перевіряли в спокійний день.; Це про повагу до своєї роботи, часу й даних інших людей.; * backup без encryption;
забутий акаунт;
переповнене cloud storage;
неповний backup;
відсутність restore-перевірки;
втрата 2FA recovery codes.; Restore має змогу бути:

</div>

- configuration: після кожної зміни

== Backup Media ==

* photos;
* contacts;
* app data;
* messages;
* settings;
* documents;
* notes;
* device configuration;
* health data у частині сценаріїв.;</div>
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>

== Backup Compression ==

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

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

* external HDD;
* external SSD;
* NAS;
* cloud object storage;
* tape;
* optical media у рідкісних сценаріях;
* remote server;
* backup appliance;
* managed backup service.; Безпека backup охоплює:
== RAID і Backup ==
<syntaxhighlight lang="bash">

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

Чи є собою offsite backup?;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

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

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

* економія storage;
* швидша передача в частині сценаріїв;
* менші витрати;
* зручніші архіви.;== Point-in-Time Recovery ==
!;== Logical Backup ==

Compression зменшує розмір backup.; * Реплікація має змогу оперативно скопіювати помилку на replica, з цієї причини вона не замінює backup.; переважні аспекти:

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

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

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

Backup у DevOps

Приклади:

переважні аспекти:

Приклад restore:

Immutable Backup

Практична роль: runbook потрібен, щоб під час аварії не згадувати бізнес-процес із голови в стресі.; * RPO і RTO допомагають говорити про backup мовою бізнесу, а не тільки техніки.; Mobile backup зберігає інформаційні дані телефону або планшета.;=== PostgreSQL production ===

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

RAID має змогу допомогти при:

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

істотно: backup — це теж копія персональних даних.; Потрібен database-aware backup.;== Personal Backup ==

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

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

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

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

переважні аспекти: Weekly backups: 12 тижнів

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

Daily backups: 30 днів

Backup Strategy

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

Захист від ransomware

Backup у Docker

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

Середа: усі зміни після неділі

Backup має змогу містити персональні й чутливі інформаційні дані.;RPO або Recovery Point Objective — скільки даних бізнес-середовище готовий втратити у часі.;

Це має змогу бути: Недоліки:

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

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

Чи відомий RPO?; * випадкового видалення;

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

human error.; Він лише створює ілюзію безпеки.; * Immutable backup став особливо важливим через ransomware.;

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>

== Backup у Kubernetes ==

Приклад:

</div>

* 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.; Ransomware має змогу шифрувати або видаляти інформаційні дані, а іноді й backup-и.;</div>

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

<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

* ransomware;
* помилкового видалення;
* compromised admin account;
* malicious insider;
* destructive scripts;
* supply chain attacks.; '''істотно:''' encrypted backup без доступного ключа не відновити.; * Практики DevOps щодо backup automation, monitoring, runbooks, CI/CD, infrastructure as code і disaster recovery drills.; * Хороший restore runbook має змогу зекономити години паніки.; Тестування має змогу включати:

== Backup Monitoring ==
'''Практична роль:''' logical backup добре підходить для малих і середніх баз, міграцій, dev-копій і вибіркового відновлення.; '''Практична роль:''' application backup — це не тільки база даних.;== Physical Backup ==
'''RTO''' або '''Recovery Time Objective''' — за який час систему потрібно відновити після збою.;<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

Чи backup охоплює database, files і configuration?; '''3-2-1 rule''' — популярне правило резервного копіювання.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Загальний характеристика

application files;
configuration;
system packages list;
databases;
logs;
SSL certificates;
cron jobs;
user data;
firewall rules;
service configs;
environment files;
deployment scripts.; Критично: якщо інформаційні дані неможливо оперативно відтворити вручну, вони потребують backup.; * простіший restore, ніж у багатьох incremental-схемах;
потрібно full backup + останній differential;
менше складності в ланцюжку.; Backup без restore-перевірки = припущення

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 без restore-перевірки — це лише надія.; Database backup — резервне копіювання бази даних.; Для MySQL і MariaDB backup має змогу включати:

переважні аспекти:

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

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

</div>

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

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

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

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

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

Application Backup

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

RTO

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

Практична роль: checklist сприяє оперативно побачити слабкі місця backup-стратегії.; Point-in-Time Recovery або PITR — відновлення системи до конкретного моменту часу.;

Вівторок: зміни після понеділка

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

Logical backup зберігає інформаційні дані у вигляді логічного представлення: SQL, dump, JSON, CSV або інший формат.; Ключі потрібно захищати, але не втрачати.; Критично: перший restore не має відбуватися під час справжньої аварії.; * Матеріали щодо 3-2-1 backup rule, RPO, RTO і restore testing.; Якщо користувацькі файли зберігаються окремо, їх теж потрібно копіювати.; Backup потрібно моніторити.;

</syntaxhighlight>

Backup охоплює production database, object storage, configuration, secrets recovery, audit logs і disaster recovery plan.; істотно: RAID підвищує доступність storage, але backup захищає історичні копії даних.;

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

== Configuration Backup ==
'''Критично:''' backup, який неможливо відновити, не захищає інформаційні дані.;== Cloud Backup ==

'''Головне правило:''' backup має бути автоматичним, захищеним, перевіреним і відновлюваним.; '''Практична роль:''' PITR надає можливість не без ускладнень відновити “вчорашній backup”, а повернутися до точного моменту перед проблемою.; * падіння сервера;
* недоступності одного вузла;
* частини infrastructure failures;
* необхідності ручного перезапуску.; Найважливіше: backup має реально відновлюватися.; 1 основна копія на сервері

* інформаційні дані тимчасові;
* систему без зайвих зусиль відтворити;
* немає production;
* немає користувацьких даних;
* це disposable environment;
* інформаційні дані генеруються автономно;
* є собою source of truth в іншому місці.;== Backup Encryption ==
'''Server backup''' охоплює інформаційні дані й конфігурацію сервера.; Важливі конфігурації:

== Server Backup ==
Носії для backup можуть бути різними:
Backup має включати database, uploads, тему, plugins, конфігурацію й SSL-related settings.; Основні переважні аспекти:

* CPU overhead;
* повільніше створення або restore;
* ризик пошкодження archive;
* не всі інформаційні дані добре стискаються;
* encrypted data часто погано стискається.; {| class="wikitable"

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

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

переважні аспекти:

</div>
</div>
</div>
== Backup Runbook ==
== PostgreSQL Backup ==
Yearly backups: 7 років

Найпоширеніша помилка з backup — думати, що він існує, поки не спробували restore.;</div>
'''Differential backup''' зберігає зміни після останнього full backup.;</div>
</div>
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
переважні аспекти:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>
- test restore щомісяця

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

'''істотно:''' Kubernetes deployment YAML можна відтворити з Git, але інформаційні дані в PersistentVolumes потрібно backup-ити окремо.; Приклад:

Неділя: full backup
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
sha256sum site-files-$(date +%F).tar.gz > site-files-$(date +%F).sha256
== Backup і Restore ==

== Backup і Security ==
Середа: зміни після вівторка
'''Проста різниця:''' backup — це копія даних, disaster recovery — це план повернення бізнесу до роботи.; '''Backup testing''' — перевірка, що backup можна відновити.;== Offsite Backup ==

* сильніше прив’язаний до версії й storage;
* складніше переносити;
* потребує правильного інструменту;
* restore має змогу вимагати сумісного середовища.;</div>
Чи захищений backup від ransomware?; Небезпека:
'''Проста аналогія:''' не тримайте всі ключі від дому в одному рюкзаку.; Monthly backups: 12 місяців
'''Найлюдяніший факт:''' backup — це не про песимізм.; - uploads: щодня

'''істотно:''' snapshot часто залежить від основного storage.;== Air-Gapped Backup ==
Понеділок: зміни після неділі

</div>

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

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.; * etcd backup;
* PersistentVolume data;
* database backup;
* namespaces;
* custom resources;
* secrets;
* config maps;
* Helm releases;
* ingress configs;
* storage class details.; Offsite backup захищає від:

особистих файлів забезпечується через Backup потрібен не тільки великим компаніям.; Restore потрібно тестувати на staging.;== переважні аспекти Backup ==

* differential backup з часом росте;
* займає більше місця, ніж incremental;
* потребує регулярних full backup.; RPO
</div>
'''істотно:''' physical backup потрібно робити інструментами, які розуміють базу даних або storage consistency.; має змогу включати:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>

Він має змогу бути:

== WordPress 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.;== Джерела ==

* backup без secrets має змогу не дозволити відновити систему;
* backup із secrets має змогу бути дуже чутливим;
* втрата encryption key має змогу зробити backup марним;
* витік backup із secrets має змогу дати доступ до production.; RTO
'''Практична роль:''' air-gapped backup — це остання лінія оборони, коли онлайн-системи скомпрометовані.; '''Immutable backup''' — backup, який не можна змінити або видалити протягом заданого періоду.;== High Availability і Backup ==

== Цікаві факти про Backup ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Deduplication''' усуває повторювані блоки або файли в backup.; - alert on failed backup

* вартість;
* швидкість;
* довговічність;
* capacity;
* encryption;
* portability;
* restore speed;
* physical safety;
* automation;
* compatibility.; Зазвичай потрібно backup-ити:

* object lock;
* write once read many;
* retention lock;
* append-only storage;
* restricted deletion policies.; Він має бути регулярним, автоматичним, зашифрованим, захищеним, збереженим offsite, контрольованим retention policy, перевіреним через restore і задокументованим у runbook.;</div>
'''Offsite backup''' — копія, що зберігається поза основною локацією.; - daily: 30 днів

* пожежі;
* крадіжки;
* знищення обладнання;
* локального ransomware;
* втрати дата-центру;
* помилки в одному cloud account;
* аварії в одній локації.;<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

'''Перевага:''' backup зменшує ціну помилки.; Хороший backup — це не без ускладнень копія.; це бізнес-процес створення додаткової копії даних, файлів, баз даних, конфігурацій або систем, щоб їх можна було відновити після втрати, помилки, збою, атаки, пошкодження, випадкового видалення або аварії виступає ключовою рисою '''Backup''' або '''резервне копіювання'''.;== Incremental Backup ==
<syntaxhighlight lang="bash">
== Backup і Privacy ==

Чи є собою immutable або offline copy?; '''істотно:''' якщо інформаційні дані жили тільки в writable layer контейнера, видалення контейнера має змогу означати втрату даних.;<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
'''Практична роль:''' differential backup — компроміс між простотою full backup і економією incremental backup.; Приклади:

* `pg_dump` для PostgreSQL;
* `mysqldump` для MySQL/MariaDB;
* export collections;
* SQL dump;
* schema export.; tar -czf site-files-$(date +%F).tar.gz /var/www/site

* випадкового DELETE;
* ransomware;
* логічної помилки;
* data corruption;
* поганої міграції;
* компрометації admin account;
* помилки application.; * Матеріали щодо cloud backup, immutable backup, object lock, ransomware protection, backup encryption і access control.; Приклад logical backup:

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

'''Головна думка:''' backup — це не файл у архіві.; Чи відомий RTO?; Він важливий; додатково реалізовано сайтів, застосунків, баз даних, серверів, хмарних систем, телефонів, ноутбуків, DevOps-процесів, SaaS-платформ і будь-яких даних, які шкода втратити.; '''Головна перевага:''' backup дає шанс виправити катастрофічну помилку без повної втрати даних.;<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
Backup — це частина DR, але не весь DR.; '''Практична роль:''' cloud backup зручний для offsite-копій, але його теж потрібно захищати, шифрувати й тестувати.; Приклад retention:

* '''3''' копії даних;
* '''2''' різні типи носіїв або сховищ;
* '''1''' копія поза основною локацією.; * database;
* `wp-content/uploads`;
* themes;
* plugins;
* `wp-config.php`;
* custom code;
* WooCommerce orders;
* media library;
* redirects;
* settings;
* backup plugin configuration.;</div>

'''Практична порада:''' якщо сервер можна оперативно відтворити через automation, backup має фокусуватися на даних, secrets і state.; '''Критично:''' реплікація й high availability — не backup.;</div>
</div>
'''істотно:''' інформаційні дані без конфігурації можуть бути як двигун без ключа: усе є собою, але платформа не стартує.; * encryption;
* access control;
* retention;
* data deletion requests;
* anonymization у частині сценаріїв;
* backups у різних регіонах;
* logs із персональними даними;
* legal requirements;
* хто має змогу restore;
* хто має змогу download backup;
* audit logs доступу до backup.; createdb appdb_restore

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Важливі документи, фото, навчальні роботи й проєкти зберігаються локально, на external drive і в хмарі.; * швидше для великих баз;
* краще підходить для production-scale;
* має змогу підтримувати point-in-time recovery;
* зберігає фізичну структуру.; Backup із перевіреним restore = реальний захист
== Приклад простого backup-плану ==
'''істотно:''' RPO — це бізнес-рішення, а не тільки технічне.; Воно означає:

* комфортно переносити між системами;
* можна відновлювати частково;
* без зайвих зусиль читати структуру;
* корисно для migration;
* часто незалежніше від storage.; Чи тестували restore?;</div>
WordPress backup має включати:
'''Практична роль:''' такий план уже відповідає на головні питання: що, коли, де, як довго й як перевіряємо.;<syntaxhighlight lang="text">

переважні аспекти:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

переважні аспекти:
'''істотно:''' backup на з цієї причини самому сервері — це краще, ніж нічого, але він не захищає від втрати всього сервера.;== Див.; додатково ==
</div>
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

'''істотно:''' incremental backup економить ресурси, але потребує дисципліни й перевірки restore-ланцюжка.; '''істотно:''' verification не замінює повний restore test, але сприяє раніше виявити пошкоджені backup-и.; * Старий external drive у шухляді — не стратегія backup, якщо ніхто не знає, чи він читається.; Якщо щось зламалося, команда має шанс повернутися до робочого стану.;</div>

Стратегія має відповідати на питання:
Вона визначає:
</div>
Це має змогу бути:
'''Full backup''' — повна копія всіх вибраних даних.; Саме з цієї причини потрібні кілька копій і перевірка.; '''Практична роль:''' backup job має бути не “десь у cron”, а контрольованою частиною operations із логами, alert-ами й відповідальними.;</div>

'''Небезпека:''' найгірший момент дізнатися, що backup неповний, — це момент, коли основні інформаційні дані вже втрачені.; У Docker істотно копіювати не сам container, а state.; Verification перевіряє, що backup не пошкоджений.; * [[Restore]]
* [[Disaster Recovery]]
* [[RPO]]
* [[RTO]]
* [[3-2-1 Backup Rule]]
* [[Snapshot]]
* [[Database Backup]]
* [[PostgreSQL Backup]]
* [[MySQL Backup]]
* [[Cloud Backup]]
* [[Immutable Backup]]
* [[Offsite Backup]]
* [[Backup Encryption]]
* [[Ransomware Protection]]
* [[High Availability]]
* [[Replication]]
* [[DevOps]]
* [[CI/CD]]
* [[Kubernetes]]
* [[Docker]]
* [[WordPress]]
* [[Application Security]]
* [[Приватність даних]]
* [[Логування]]
* [[Документація]]

'''High Availability''' або '''HA''' зменшує downtime, але не замінює backup.; Чи знаємо, які інформаційні дані критичні?;== Disaster Recovery ==
організація використовує immutable backup, offsite-копію, MFA, ізольовані backup credentials і регулярні recovery tests.; '''Application backup''' має враховувати все, що потрібно для відновлення застосунку.; * Документація баз даних щодо logical backup, physical backup, WAL, binary logs і point-in-time recovery.; '''Критично:''' якщо ransomware має змогу видалити або зашифрувати backup, backup не є собою достатнім захистом.; Найбільше він потрібен саме тоді, коли вже пізно шукати, де вона лежить.; * Backup має змогу бути небезпечним, якщо його вкрали: він часто містить усю систему.; * складніше автоматизувати;
* повільніший restore;
* потребує фізичної дисципліни;
* ризик застарівання носіїв;
* складніше тестувати часто.; Команда має змогу місяцями думати, що інформаційні дані захищені.;</div>

== 3-2-1 Backup Rule ==

'''Disaster Recovery''' або '''DR''' — ширший план відновлення після серйозної аварії.; Ці два поняття нерозривні.; Файл має змогу бути скопійований, архів має змогу лежати в хмарі, snapshot має змогу створюватися щодня, але справжній backup існує тільки тоді, коли з нього реально можна відновити інформаційні дані.; - primary backup storage

* скільки backup-ів зберігати;
* як довго;
* які backup-и архівувати;
* які видаляти;
* які потрібні для compliance;
* які потрібні для rollback;
* скільки коштує storage;
* чи є собою legal requirements.; '''Практична порада:''' для InnoDB істотно використовувати consistent backup-підхід, щоб не отримати пошкоджену або неповну копію.; Перевірка:

== Backup Verification ==

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

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* чи backup job успішно завершився;
* скільки тривав backup;
* розмір backup;
* чи не став розмір раптово нульовим;
* чи створився файл;
* чи пройшла перевірка integrity;
* чи доступний storage;
* чи не закінчується місце;
* чи не минув термін ключів;
* чи не порушена retention policy;
* чи пройшов test restore.; |-
| 24 години
| можна втратити інформаційні дані за останню добу
|-
| 1 година
| можна втратити максимум годину змін
|-
| 5 хвилин
| потрібні дуже часті backup або журналювання
|-
| майже 0
| потрібна складна high availability і replication-стратегія
|}

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Backup має обмеження.;<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

'''Cloud backup''' — резервна копія, що зберігається в хмарному сховищі або керованому backup-сервісі.;<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Недоліки:
'''Практична роль:''' deduplication особливо корисна, коли щоденні backup-и містять багато однакових даних.; * швидкого rollback;
* короткострокового захисту;
* перед оновленням;
* перед міграцією;
* cloud volumes;
* virtual machines;
* development environments;
* testing.; Якщо зникне весь storage або акаунт, snapshot має змогу зникнути разом із ним.; У Kubernetes потрібно думати не лише про manifests, а й про persistent data.; з цієї причини в професійних системах важлива не лише фраза “ми робимо backup”, а питання: “коли востаннє ми перевіряли restore?”

* restore на test environment;
* перевірку checksum;
* запуск application після restore;
* перевірку database integrity;
* перевірку permissions;
* перевірку файлів;
* вимірювання restore time;
* симуляцію disaster recovery;
* перевірку documentation;
* перевірку доступу до ключів encryption.;</div>
Використовуються physical backups, WAL archiving, PITR, регулярні restore drills і monitoring backup jobs.; Це здатність повернути інформаційні дані й роботу системи тоді, коли щось пішло не так.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* backup не створився;
* backup пошкоджений;
* restore не тестувався;
* backup містить застарілі інформаційні дані;
* backup не охоплює важливі файли;
* backup зберігається поруч із production;
* backup не зашифрований;
* encryption key втрачено;
* backup видалено ransomware;
* restore триває занадто довго;
* retention занадто короткий;
* backup містить приватні інформаційні дані без контролю;
* backup не відповідає compliance;
* ніхто не знає, як відновлювати.; HA має змогу захистити від:
Рекомендовано:
Чи є собою alert на failed backup?;== Типові помилки початківців ==

</div>

== Backup Testing ==

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Але часто краще відновлювати сервер через infrastructure as code, а backup робити для даних і важливої конфігурації.; * що саме можна втратити;
* за який час це можна відновити;
* чи є собою приховані важливі файли;
* чи не зберігаються secrets;
* чи є собою документація.;</div>

Ризики:

<syntaxhighlight lang="bash">

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

* неправильні IAM permissions;
* vendor lock-in;
* витрати на storage і restore;
* залежність від інтернету;
* помилка cloud account;
* неправильний region;
* відсутність restore testing.; Для PostgreSQL часто використовують:
pg_restore -d appdb_restore appdb.dump

'''Практична роль:''' full backup — це найпростіша для розуміння модель: “ось повна копія всього на цей момент”.; Чи ключі шифрування доступні для recovery?;=== Особистий ноутбук ===
як ілюстрація:

Але snapshot не завжди дорівнює повноцінному backup.; * Практики privacy, compliance, retention policy, audit і security incident response.;== Цікавий факт ==
Backup обов’язковий, якщо є собою:

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

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

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

'''Backup''' — це фундаментальний механізм захисту даних від втрати, помилок, атак і аварій.; '''Backup strategy''' — план, який визначає, що, як, де, коли й навіщо копіюється.;<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

DR охоплює:

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

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

'''Backup''' — це створення резервної копії.; '''Критично:''' без ускладнень скопіювати файли бази даних під час її роботи не завжди безпечно.; Вівторок: усі зміни після неділі
</div>
Потрібно контролювати:

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

має змогу включати:

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

* менше storage;
* швидші backup-и після першого;
* економія costs;
* ефективність для схожих datasets.;<syntaxhighlight lang="text">

!; має змогу включати:

* logical backup;
* physical backup;
* dump;
* snapshot;
* continuous backup;
* point-in-time recovery;
* replication-based backup у частині сценаріїв.; * Найцінніші інформаційні дані часто не в коді, а в базі даних і user uploads.; - deployment manifests

</div>

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* `pg_dump`;
* `pg_restore`;
* `pg_basebackup`;
* WAL archiving;
* point-in-time recovery;
* physical backup tools;
* managed cloud backups.; Шифрування потрібне для захисту:

* складніша платформа;
* restore залежить від metadata;
* має змогу бути vendor-specific;
* потребує перевірки integrity.; - quarterly disaster recovery drill
У * перевіряти, що backup передбачено всі потрібні інформаційні дані.; * Практики data backup і disaster recovery.; Приклади:

- database: щогодини incremental/WAL, щодня full

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
'''Практична порада:''' окремо зберігайте recovery codes для 2FA, бо після втрати телефону саме вони можуть бути важливішими за сам телефон.;

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

випадкового видалення;
ransomware;
пожежі;
крадіжки сервера;
помилки застосунку;
пошкодження даних;
неправильного deployment;
видалення таблиці в базі.; Основна ідея: backup — це запасний шлях назад, коли основні інформаційні дані зникли, зламалися або стали непридатними.; * backup;
restore procedures;
failover;
alternate infrastructure;
communication plan;
incident roles;
runbooks;
recovery priorities;
RPO;
RTO;
dependency map;
testing;
post-incident review.; Для production потрібні encryption, offsite copy, monitoring і restore test.;

</syntaxhighlight>

Чи backup зашифрований?;=== Сайт малого бізнесу ===

Чи є собою runbook?; - offsite cloud storage

Backup encryption — шифрування резервних копій.; Privacy rules не зникають лише з цієї причини, що інформаційні дані лежать в архіві.; * персональних даних;

фінансових даних;
медичних даних;
credentials;
source code;
бізнес-документів;
database dumps;
cloud archives;
external drives.; Критично: WordPress backup без бази даних або без uploads — неповний.; Практична порада: secrets мають бути збережені так, щоб їх можна було відновити, але не можна було без зайвих зусиль викрасти.; Понеділок: зміни за понеділок

Retention:

Неділя: full backup Де зберігаємо: Критерії вибору:

істотно: носій backup теж має змогу зламатися.; 1 backup на окремому storage

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

Backup і Secrets

* повним;
* частковим;
* file-level;
* database-level;
* point-in-time;
* bare-metal;
* application-level;
* disaster recovery restore.; !; * offsite storage;
* масштабованість;
* automation;
* lifecycle policies;
* encryption;
* geo-replication у частині сценаріїв;
* object lock;
* managed retention;
* зручний доступ.; Якщо помилка потрапила на primary, вона має змогу оперативно потрапити й на replica.; У DevOps backup має бути частиною production-процесу.; '''Найлюдяніший сенс:''' backup особистих фото й документів потрібен не для “айтішності”, а щоб не втратити роки життя через один зламаний диск.; * де лежать backup-и;
* як отримати доступ;
* які credentials потрібні;
* як розшифрувати;
* як відновити database;
* як відновити files;
* як перевірити application;
* кого повідомити;
* як оцінити RPO/RTO;
* як діяти при failed restore;
* як перевірити integrity;
* як документувати incident.; Чи моніторяться backup jobs?;</div>

mysqldump --single-transaction appdb > appdb.sql
'''Incremental backup''' зберігає тільки зміни після попереднього backup.;== Snapshot ==
Важливі перевірки:
RAID не захищає від:

</div>

* економить місце;
* швидше створюється;
* менше навантаження.; Але навіть тоді потрібно розуміти:
Відновити базу на стан 2026-05-09 13:42:10,

Приклад:

- immutable monthly archive

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

істотно: для великих production-баз одного `pg_dump` має змогу бути замало.; Чи є собою 3 копії?; Він потрібен для особистих файлів, застосунків, баз даних, серверів, сайтів, SaaS-систем, хмарної інфраструктури й бізнес-процесів.;== Mobile Backup == істотно: “це неважливо” має бути усвідомленим рішенням, а не випадковим відкриттям після аварії.;</syntaxhighlight> pg_dump -Fc -d appdb -f appdb.dump

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