Backup

== конкурентні переваги Backup ==

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

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

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

Приклади: Backup потрібно моніторити. Backup strategy — план, який визначає, що, як, де, коли й навіщо копіюється. * ransomware;

• помилкового видалення;
• compromised admin account;
• malicious insider;
• destructive scripts;
• supply chain attacks. 1 backup на окремому storage

Можливі проблеми: Воно означає:

Database backup — резервне копіювання бази даних. Якщо щось зламалося, команда має шанс повернутися до робочого стану. Restore потрібно тестувати на staging. * Реплікація здатна оперативно скопіювати помилку на replica, тому вона не замінює backup. * `pg_dump`;

• `pg_restore`;
• `pg_basebackup`;
• WAL archiving;
• point-in-time recovery;
• physical backup tools;
• managed cloud backups. * використовувати 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 Deduplication

Критично: реплікація й high availability — не backup.

Backup encryption — шифрування резервних копій. Потрібно контролювати: Перевірка: Backup — це фундаментальний механізм захисту даних від втрати, помилок, атак і аварій. * consistency;

• transactions;
• write-ahead logs;
• schema;
• indexes;
• roles;
• extensions;
• stored procedures;
• large objects;
• permissions;
• restore time;
• data size;
• application compatibility. критично: це лише простий приклад архівування файлів. Недоліки:

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

Недоліки: Практична роль: application backup — це не тільки база даних. * неправильні IAM permissions;

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

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

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

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

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

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

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

критично: RAID підвищує доступність storage, але backup захищає історичні копії даних. Він важливий; так само реалізовано сайтів, застосунків, баз даних, серверів, хмарних систем, телефонів, ноутбуків, DevOps-процесів, SaaS-платформ і будь-яких даних, які шкода втратити. Приклад restore: Потрібно враховувати:

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

У * перевіряти, що backup передбачено всі потрібні інформаційні дані.

== Snapshot ==

* etcd backup;
* PersistentVolume data;
* database backup;
* namespaces;
* custom resources;
* secrets;
* config maps;
* Helm releases;
* ingress configs;
* storage class details. Для MySQL і MariaDB backup здатна включати:

</div>

'''Point-in-Time Recovery''' або '''PITR''' — відновлення системи до конкретного моменту часу. Він має бути регулярним, автоматичним, зашифрованим, захищеним, збереженим offsite, контрольованим retention policy, перевіреним через restore і задокументованим у runbook. - offsite cloud storage

До secrets належать:
Чи виступає як 3 копії?== Ризики і обмеження Backup ==
'''Практична роль:''' air-gapped backup — це остання лінія оборони, коли онлайн-системи скомпрометовані. '''Практична роль:''' compression корисна для текстових dumps, logs і документів, але менш ефективна для вже стиснених фото, відео або encrypted archives. '''критично:''' backup — це теж копія персональних даних.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>

</div>

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

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

'''Критично:''' backup має бути захищений від тієї ж атаки, яка знищує основні інформаційні дані. * Backup здатна бути небезпечним, якщо його вкрали: він часто містить усю систему. Що означає
Ransomware здатна шифрувати або видаляти інформаційні дані, а іноді й backup-и. '''Air-gapped backup''' — копія, фізично або логічно відокремлена від основної мережі. Захист містить:

<syntaxhighlight lang="bash">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''критично:''' Kubernetes deployment YAML можна відтворити з Git, але інформаційні дані в PersistentVolumes потрібно backup-ити окремо. Найважливіше: backup має реально відновлюватися.</div>

* application files;
* configuration;
* system packages list;
* databases;
* logs;
* SSL certificates;
* cron jobs;
* user data;
* firewall rules;
* service configs;
* environment files;
* deployment scripts.== Backup і Privacy ==
== Висновок ==
1 backup у хмарі або іншому дата-центрі

</div>

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

'''Практична порада:''' для InnoDB критично використовувати consistent backup-підхід, щоб не отримати пошкоджену або неповну копію. * backup без secrets здатна не дозволити відновити систему;
* backup із secrets здатна бути дуже чутливим;
* втрата encryption key здатна зробити backup марним;
* витік backup із secrets здатна дати доступ до production. Для production потрібні encryption, offsite copy, monitoring і restore test. '''критично:''' RPO — це бізнес-рішення, а не тільки технічне. Він потрібен для особистих файлів, застосунків, баз даних, серверів, сайтів, SaaS-систем, хмарної інфраструктури й бізнес-процесів. Понеділок: зміни за понеділок
'''Небезпека:''' backup здатна створити фальшиве відчуття безпеки, якщо ніхто не перевіряє, що з нього реально можна відновитися. * Snapshot зручний, але не завжди виступає як повноцінною резервною копією. * RPO і RTO допомагають говорити про backup мовою бізнесу, а не тільки техніки. Сайт здатна відновитися без контенту або без медіа. * чи backup job успішно завершився;
* скільки тривав backup;
* розмір backup;
* чи не став розмір раптово нульовим;
* чи створився файл;
* чи пройшла перевірка integrity;
* чи доступний storage;
* чи не закінчується місце;
* чи не минув термін ключів;
* чи не порушена retention policy;
* чи пройшов test restore. конкурентні переваги:
Вівторок: усі зміни після неділі

Важливі конфігурації:
== Backup і Ransomware ==
</div>

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

'''RPO''' або '''Recovery Point Objective''' — скільки даних бізнес-середовище готовий втратити у часі.</div>
'''Найлюдяніший факт:''' backup — це як парасолька.== Приклад простого backup-плану ==
'''Snapshot''' — знімок стану системи, диска, volume, бази даних або storage на певний момент. '''Application backup''' має враховувати все, що потрібно для відновлення застосунку.== Incremental Backup ==

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

* економія storage;
* швидша передача в частині сценаріїв;
* менші витрати;
* зручніші архіви. Саме тому потрібні кілька копій і перевірка.</div>

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

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

* production database;
* користувацькі файли;
* фінансові інформаційні дані;
* персональні інформаційні дані;
* бізнес-документи;
* source code;
* сайт або магазин;
* конфігурації серверів;
* SaaS-продукт;
* медичні або юридичні записи;
* навчальні або творчі роботи;
* інформаційні дані, які неможливо швидко відтворити. Потрібен database-aware 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.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Це здатна бути:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

конкурентні переваги:

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

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Середа: усі зміни після неділі
Retention:

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

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

<syntaxhighlight lang="text">

'''Runbook''' — покрокова інструкція для backup і restore. * Старий external drive у шухляді — не стратегія backup, якщо ніхто не знає, чи він читається. pg_dump -Fc -d appdb -f appdb.dump
</div>
== Air-Gapped Backup ==
Шифрування потрібне для захисту:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

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

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

• менше ризику remote deletion;
• корисно для critical data.== 3-2-1 Backup Rule ==

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

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

• restore procedures;
• failover;
• alternate infrastructure;
• communication plan;
• incident roles;
• runbooks;
• recovery priorities;
• RPO;
• RTO;
• dependency map;
• testing;
• post-incident review. Найпоширеніша помилка з backup — думати, що він існує, поки не спробували restore. * інтуїтивно переносити між системами;
• можна відновлювати частково;
• швидко читати структуру;
• корисно для migration;
• часто незалежніше від storage.== Цікавий факт ==

Backup можна спростити, якщо: Чи backup містить database, files і configuration? - monthly: 12 місяців Де зберігаємо:

Приклад:

High Availability або HA зменшує downtime, але не замінює backup. * захист від втрати даних;

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

Проста різниця: RPO — скільки даних можна втратити, RTO — скільки часу можна бути недоступним. Небезпека: найгірший момент дізнатися, що backup неповний, — це момент, коли основні інформаційні дані вже втрачені. sha256sum site-files-$(date +%F).tar.gz > site-files-$(date +%F).sha256

• 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
• Приватність даних
• Логування
• Документація

Differential backup зберігає зміни після останнього full backup. Backup здатна містити персональні й чутливі інформаційні дані. Це здатність повернути інформаційні дані й роботу системи тоді, коли щось пішло не так. компанія-користувач використовує immutable backup, offsite-копію, MFA, ізольовані backup credentials і регулярні recovery tests.== Backup і Security ==

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

Недоліки: Full backup — повна копія всіх вибраних даних.== Тематичні мітки == </syntaxhighlight>

Недоліки:

Неділя: full backup

Перевага: backup зменшує ціну помилки.=== Захист від ransomware ===

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

Backup у Kubernetes

• 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. Чим менший RPO, тим дорожча й складніша платформа. Практична порада: secrets мають бути збережені так, щоб їх можна було відновити, але не можна було швидко викрасти. критично: backup на тому самому сервері — це краще, ніж нічого, але він не захищає від втрати всього сервера. Якщо зникне весь storage або акаунт, snapshot здатна зникнути разом із ним. Неділя: full backup

Проста аналогія: не тримайте всі ключі від дому в одному рюкзаку. Найлюдяніший факт: backup — це не про песимізм. RTO або Recovery Time Objective — за який час систему потрібно відновити після збою.

Backup Media

• 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. * займає більше місця;
• довше створюється;
• здатна створювати більше навантаження;
• дорожчий у storage. pg_restore -d appdb_restore appdb.dump

Backup і Secrets

критично: physical backup потрібно робити інструментами, які розуміють базу даних або storage consistency. це бізнес-процес створення додаткової копії даних, файлів, баз даних, конфігурацій або систем, щоб їх можна було відновити після втрати, помилки, збою, атаки, пошкодження, випадкового видалення або аварії виступає ключовою рисою Backup або резервне копіювання. mysqldump --single-transaction appdb > appdb.sql </syntaxhighlight>

Чи відомий RTO?

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

Як часто:

• інший дата-центр;
• хмарне сховище;
• інший регіон;
• фізичний носій в іншому місці;
• окремий акаунт;
• окрема організаційна зона. - database: щогодини incremental/WAL, щодня full

! критично: якщо інформаційні дані жили тільки в writable layer контейнера, видалення контейнера здатна означати втрату даних.== Цікаві факти про Backup ==

createdb appdb_restore

Backup Verification

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

Відновити базу на стан 2026-05-09 13:42:10,

Backup Monitoring

</syntaxhighlight>

Backup Strategy

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

Backup має обмеження. * де лежать backup-и;

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

Що копіюємо:

Чи виступає як immutable або offline copy?

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

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

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

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

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

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

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

• менше storage;
• швидші backup-и після першого;
• економія costs;
• ефективність для схожих datasets. * персональних даних;
• фінансових даних;
• медичних даних;
• credentials;
• source code;
• бізнес-документів;
• database dumps;
• cloud archives;
• external drives.== Point-in-Time Recovery ==

критично: для великих production-баз одного `pg_dump` здатна бути замало.

• пожежі;
• крадіжки;
• знищення обладнання;
• локального ransomware;
• втрати дата-центру;
• помилки в одному cloud account;
• аварії в одній локації. Але snapshot не завжди дорівнює повноцінному backup. Часто потрібні physical backups і WAL archiving. Особистий backup потрібен для:

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

Ризики:

== Personal Backup ==
Backup обов’язковий, якщо виступає як:
- daily: 30 днів

</div>

* Практики data backup і disaster recovery. '''критично:''' носій backup теж здатна зламатися. * Матеріали щодо cloud backup, immutable backup, object lock, ransomware protection, backup encryption і access control.</div>
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
'''Проста різниця:''' backup — це копія даних, disaster recovery — це план повернення бізнесу до роботи. '''Практична роль:''' checklist оптимізує оперативно побачити слабкі місця backup-стратегії.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

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

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

- alert on failed backup

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

Чи виступає як alert на failed backup? {| class="wikitable"

* випадкового DELETE;
* ransomware;
* логічної помилки;
* data corruption;
* поганої міграції;
* компрометації admin account;
* помилки application. RPO
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== PostgreSQL Backup ==

!== MySQL і MariaDB Backup ==
<syntaxhighlight lang="text">
== Mobile Backup ==
== Differential Backup ==
== RAID і Backup ==
== Приклад команд для простого file backup ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Хороший backup — це не без зусиль копія.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

'''Offsite backup''' — копія, що зберігається поза основною локацією. - weekly: 12 тижнів
- test restore щомісяця

</div>

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

Див. так само

критично: encrypted backup без доступного ключа не відновити. Чи знаємо, які інформаційні дані критичні?

• Backup без restore-перевірки — це лише надія.=== Особистий ноутбук ===

конкурентні переваги:

• швидкого rollback;
• короткострокового захисту;
• перед оновленням;
• перед міграцією;
• cloud volumes;
• virtual machines;
• development environments;
• testing. * restore здатна бути складнішим;
• потрібен ланцюжок backup-ів;
• пошкодження одного елемента здатна вплинути на відновлення. Команда здатна місяцями думати, що інформаційні дані захищені. Backup без restore-перевірки = припущення

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

</div>

'''Критично:''' перший restore не має відбуватися під час справжньої аварії. * encryption keys;
* key rotation;
* доступ до ключів;
* recovery ключів;
* хто здатна decrypt;
* де зберігаються keys;
* чи не лежить key поруч із backup. '''Критично:''' backup часто містить усе найцінніше.<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

* вартість;
* швидкість;
* довговічність;
* capacity;
* encryption;
* portability;
* restore speed;
* physical safety;
* automation;
* compatibility.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* складніша платформа;
* restore залежить від metadata;
* здатна бути vendor-specific;
* потребує перевірки integrity. '''Критично:''' без зусиль скопіювати файли бази даних під час її роботи не завжди безпечно. здатна включати:
'''Retention''' — політика зберігання backup-ів. PITR корисний для:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Головна думка:''' backup strategy — це не “раз на день щось кудись копіюємо”, а продуманий план виживання даних. {| class="wikitable"
'''Головна перевага:''' backup дає шанс виправити катастрофічну помилку без повної втрати даних. 1 основна копія на сервері
'''Logical backup''' зберігає інформаційні дані у вигляді логічного представлення: SQL, dump, JSON, CSV або інший формат.</div>
Backup здатна включати:
</div>

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

Hourly backups: 24 години

HA здатна захистити від:

* скільки backup-ів зберігати;
* як довго;
* які backup-и архівувати;
* які видаляти;
* які потрібні для compliance;
* які потрібні для rollback;
* скільки коштує storage;
* чи виступає як legal requirements. * differential backup з часом росте;
* займає більше місця, ніж incremental;
* потребує регулярних full backup.

• сильніше прив’язаний до версії й storage;
• складніше переносити;
• потребує правильного інструменту;
• restore здатна вимагати сумісного середовища. Чи виступає як offsite backup? Файл здатна бути скопійований, архів здатна лежати в хмарі, snapshot здатна створюватися щодня, але справжній backup існує тільки тоді, коли з нього реально можна відновити інформаційні дані.

Physical Backup

- uploads: щодня

Full Backup

як приклад: Restore здатна бути:

RTO

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

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

Практична роль: такий план уже відповідає на головні питання: що, коли, де, як довго й як перевіряємо. Backup має включати database, uploads, тему, plugins, конфігурацію й SSL-related settings. Ризики: - quarterly disaster recovery drill

Недоліки:

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

Приклад:

Джерела

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

Чи виступає як retention policy?

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

Backup Runbook

Immutable Backup

- hourly: 48 годин

Compression зменшує розмір backup. Privacy rules не зникають лише тому, що інформаційні дані лежать в архіві. Ключі потрібно захищати, але не втрачати. за хвилину до випадкового DELETE.

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

- primary backup storage

Практична роль: PITR дає можливість не без зусиль відновити “вчорашній backup”, а повернутися до точного моменту перед проблемою. Це здатна бути: Практична роль: backup job має бути не “десь у cron”, а контрольованою частиною operations із логами, alert-ами й відповідальними. * Практики privacy, compliance, retention policy, audit і security incident response.SEO title: Backup — резервне копіювання даних, restore, snapshots, 3-2-1 rule, disaster recovery і безпека

SEO keywords: Backup, резервне копіювання, restore, recovery, data backup, database backup, cloud backup, 3-2-1 backup rule, full backup, incremental backup, differential backup, snapshot, disaster recovery, RPO, RTO, backup encryption, immutable backup, offsite backup, ransomware protection, backup strategy, PostgreSQL backup, server backup

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки. 

}}

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

Тестування здатна включати:

! * Матеріали щодо 3-2-1 backup rule, RPO, RTO і restore testing.

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

У Kubernetes потрібно думати не лише про manifests, а й про persistent data. Стратегія має відповідати на питання: Daily backups: 30 днів

конкурентні переваги:

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

Приклад:

• database;
• `wp-content/uploads`;
• themes;
• plugins;
• `wp-config.php`;
• custom code;
• WooCommerce orders;
• media library;
• redirects;
• settings;
• backup plugin configuration. Недоліки:

</syntaxhighlight> Приклад logical backup:

PostgreSQL production

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

Immutable backup здатна використовувати:

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

  == RPO ==
  
  <div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
  
  конкурентні переваги:
  
  * API keys;
  * database passwords;
  * private keys;
  * certificates;
  * encryption keys;
  * OAuth credentials;
  * cloud credentials;
  * recovery codes.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
  
  Критерії вибору:
  
  * photos;
  * contacts;
  * app data;
  * messages;
  * settings;
  * documents;
  * notes;
  * device configuration;
  * health data у частині сценаріїв. '''критично:''' “це неважливо” має бути усвідомленим рішенням, а не випадковим відкриттям після аварії. конкурентні переваги:
  
  <syntaxhighlight lang="text">
  
  Verification перевіряє, що backup не пошкоджений. Для баз даних критично враховувати:
  
  == Offsite Backup ==
  
  <div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
  
  * checksum;
  * archive validation;
  * database consistency check;
  * restore dry run;
  * file count comparison;
  * sample read;
  * cryptographic hash;
  * application smoke test after restore. Недоліки:
  Поширені помилки:
  </div>
  
  <div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
  
  '''Практична роль:''' logical backup добре підходить для малих і середніх баз, міграцій, dev-копій і вибіркового відновлення. Це про повагу до своєї роботи, часу й даних інших людей.</div>
  
  Чи ключі шифрування доступні для recovery?<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
  
  * object lock;
  * write once read many;
  * retention lock;
  * append-only storage;
  * restricted deletion policies. Якщо помилка потрапила на primary, вона здатна оперативно потрапити й на replica. '''критично:''' інформаційні дані без конфігурації можуть бути як двигун без ключа: усе виступає як, але платформа не стартує.</div>
  
  Він здатна бути:
  
  == Cloud Backup ==
  
  - PostgreSQL database
  
  </div>
  
  Недоліки:
  
  <div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
  
  == Коли Backup обов’язковий ==
  
  конкурентні переваги:
  
  === SaaS-застосунок ===
  
  </div>
  

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

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

Чи тестували restore? * external HDD;

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

DR містить:

• offline external drive;
• tape backup;
• isolated storage;
• disconnected archive;
• restricted offline vault. Backup — це частина DR, але не весь DR.== Backup Retention ==

Monthly backups: 12 місяців

Backup у Docker

WordPress Backup

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

• backup без encryption;
• забутий акаунт;
• переповнене cloud storage;
• неповний backup;
• відсутність restore-перевірки;
• втрата 2FA recovery codes. Incremental backup зберігає тільки зміни після попереднього backup. Weekly backups: 12 тижнів

Чи захищений backup від ransomware? Рекомендовано:

• 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 — це не файл у архіві. * Найкращий backup-план той, який уже перевіряли в спокійний день. * Практики DevOps щодо backup automation, monitoring, runbooks, CI/CD, infrastructure as code і disaster recovery drills.

конкурентні переваги:

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

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

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

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

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

Logical Backup

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

• 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.

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

  Snapshots використовують для:
  '''Disaster Recovery''' або '''DR''' — ширший план відновлення після серйозної аварії. Найбільше він потрібен саме тоді, коли вже пізно шукати, де вона лежить. '''Практична роль:''' cloud backup зручний для offsite-копій, але його теж потрібно захищати, шифрувати й тестувати.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
  '''критично:''' incremental backup економить ресурси, але потребує дисципліни й перевірки restore-ланцюжка. Понеділок: зміни після неділі
  
  <syntaxhighlight lang="bash">
  '''Практична порада:''' якщо сервер можна оперативно відтворити через automation, backup має фокусуватися на даних, secrets і state. '''Backup testing''' — перевірка, що backup можна відновити. * Документація баз даних щодо logical backup, physical backup, WAL, binary logs і point-in-time recovery. конкурентні переваги:
  Приклади:
  == Disaster Recovery ==
  
  <div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
  
  Mobile backup зберігає інформаційні дані телефону або планшета.== Configuration Backup ==
  
  '''Backup''' — це створення резервної копії. * швидше для великих баз;
  * краще підходить для production-scale;
  * здатна підтримувати point-in-time recovery;
  * зберігає фізичну структуру. Backup здатна охоплювати:
  
  * restore на test environment;
  * перевірку checksum;
  * запуск application після restore;
  * перевірку database integrity;
  * перевірку permissions;
  * перевірку файлів;
  * вимірювання restore time;
  * симуляцію disaster recovery;
  * перевірку documentation;
  * перевірку доступу до ключів encryption. '''Physical backup''' копіює фізичні файли бази або storage-level інформаційні дані у підтримуваний спосіб. здатна включати:
  
  * backup не створився;
  * backup пошкоджений;
  * restore не тестувався;
  * backup містить застарілі інформаційні дані;
  * backup не містить важливі файли;
  * backup зберігається поруч із production;
  * backup не зашифрований;
  * encryption key втрачено;
  * backup видалено ransomware;
  * restore триває занадто довго;
  * retention занадто короткий;
  * backup містить приватні інформаційні дані без контролю;
  * backup не відповідає compliance;
  * ніхто не знає, як відновлювати. '''Критично:''' backup, який неможливо відновити, не захищає інформаційні дані.== Backup і Restore ==
  
  Небезпека:
  
  </div>
  
  '''критично:''' snapshot часто залежить від основного storage. Він лише створює ілюзію безпеки. * offsite storage;
  * масштабованість;
  * automation;
  * lifecycle policies;
  * encryption;
  * geo-replication у частині сценаріїв;
  * object lock;
  * managed retention;
  * зручний доступ. '''RAID''' оптимізує пережити відмову диска, але не виступає як backup. * Immutable backup став особливо важливим через ransomware. Якщо його вкрадуть, це здатна бути не менш небезпечно, ніж злам production. ! Чи виступає як runbook? * простіше відновлення;
  * одна повна точка копії;
  * менше залежностей між backup-файлами;
  * інтуїтивно для базової копії.</div>
  
  - immutable monthly archive
  
  * економить місце;
  * швидше створюється;
  * менше навантаження.</div>
  
  '''критично:''' verification не замінює повний restore test, але оптимізує раніше виявити пошкоджені backup-и.
  

Чи backup зашифрований? Практична роль: deduplication особливо корисна, коли щоденні backup-и містять багато однакових даних. * logical backup;

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

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

Backup охоплює production database, object storage, configuration, secrets recovery, audit logs і disaster recovery plan. * Найцінніші інформаційні дані часто не в коді, а в базі даних і user uploads.== Application Backup ==

• CPU overhead;
• повільніше створення або restore;
• ризик пошкодження archive;
• не всі інформаційні дані добре стискаються;
• encrypted data часто погано стискається. * Хороший restore runbook здатна зекономити години паніки. Критично: мовчазний failed backup — одна з найнебезпечніших проблем.

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

High Availability і Backup

Конфігурації часто забувають копіювати, хоча без них платформа здатна не запуститися. Практична роль: differential backup — компроміс між простотою full backup і економією incremental backup.

Критично: WordPress backup без бази даних або без uploads — неповний. * Backup

• Резервне копіювання
• Restore
• Recovery
• Data Backup
• Database Backup
• Cloud Backup
• 3-2-1 Backup Rule
• Full Backup
• Incremental Backup
• Differential Backup
• Snapshot
• Disaster Recovery
• RPO
• RTO
• Backup Encryption
• Immutable Backup
• Offsite Backup
• Ransomware Protection
• Backup Strategy
• PostgreSQL Backup
• Server Backup
• Документація