Відновлення до моменту часу проти snapshot: що ви втрачаєте

Хтось виконує DELETE без умови WHERE о 16:15. Ваше найновіше резервне копіювання було зроблено о 03:00. Усе, що відбулося між цими моментами, втрачено, і жодне відновлення не поверне це назад.

Ця прогалина має назву — цільова точка відновлення, або RPO, — і рішення між відновленням до моменту часу та snapshot повністю залежить від того, наскільки великою ви готові її прийняти.

Дві моделі

Snapshot фіксують стан ваших даних у певний момент. Вони запускаються за розкладом, зазвичай щодня вночі. Відновлення з snapshot повертає вас саме до стану на момент його створення, а все, що відбулося після цього, буде втрачено.

Відновлення до моменту часу поєднує базову резервну копію з безперервним потоком журналу попереднього запису бази даних. Оскільки кожна зміна записується в правильному порядку, ви можете відтворити стан на будь-який момент, для якого зберігся журнал, — зокрема на 16:14, за хвилину до видалення.

Різниця тут не поступова. Це різниця між «ми втратили день» і «ми втратили хвилину».

Число, яке визначає вибір

Чесно дайте відповідь на одне запитання: що станеться, якщо ви втратите все, що було записано за останні дванадцять годин?

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

Для будь-чого, де клієнти записують дані, відповідь зазвичай звучить приблизно так: «Нам доведеться написати людям і все пояснити». Замовлення, яких більше не існує. Завантажені файли, що зникли. Повідомлення, які були надіслані, але тепер відсутні. Лише витрати на підтримку зазвичай перевищують різницю у витратах на інфраструктуру за цілий рік.

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

Для чого snapshot справді добре підходять

Це не гірший продукт. Вони захищають від збоїв, від яких PITR не рятує:

• Повна втрата диска. Snapshot в окремому сховищі відновлює все, зокрема файли, якими не керує база даних.
• Швидкий грубий відкат. Скасувати невдалу міграцію в staging-середовищі зі snapshot швидше, ніж відтворювати журнал.
• Вартість. Зберігати одну копію на день дешевше, ніж зберігати кожен запис.
• Простота. Менша кількість компонентів — це реальна операційна перевага, особливо для невеликої команди.

Проблема починається тоді, коли snapshot вважають достатнім захистом для бази даних із безперервним потоком записів.

Якою є ціна PITR

Це не безкоштовно, і про витрати варто сказати прямо:

• Сховище. Ви зберігаєте базову резервну копію, а також кожен запис за весь період зберігання.
• Складність. Архівування має працювати безперервно. Якщо archiver непомітно не працював тиждень, ваше доступне для відновлення вікно закінчується тиждень тому — саме тому моніторинг архіву так само важливий, як і його налаштування.
• Час відновлення. Відтворення журналу займає більше часу, ніж відновлення snapshot. RPO покращується, а RTO зазвичай погіршується.

Саме цей компроміс часто застає людей зненацька. PITR означає, що ви втратите менше даних, але не те, що швидше повернетеся до роботи.

Багаторівнева відповідь, яка насправді потрібна більшості команд

На практиці це не вибір між двома варіантами. Для production-баз даних зазвичай потрібні три рівні, оскільки вони виходять з ладу трьома різними способами:

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

Логічні дампи — щодня, зі зберіганням поза хостом. pg_dump за своєю природою є portable і узгодженим. Його можна відновити на іншій major version, в іншого провайдера або на ноутбуці — саме це потрібно, коли проблема пов’язана з платформою, а не з даними.

Безперервне архівування — коли в базі є клієнтські дані. Це рівень, який перетворює «ми втратили сьогоднішній день» на «ми втратили хвилину».

Кожен рівень покриває те, чого не покривають інші. Snapshot не допоможе перейти до іншого провайдера. Логічний дамп не допоможе відновити файл, якого не було в базі даних. Жоден із них не допоможе скасувати видалення, виконане чотири години тому.

Де тут Dockup

Dockup надає два рівні, які покривають найпоширеніші збої, і важливо чітко розуміти, які саме.

Snapshot томів — за запитом або за розкладом із заданою кількістю копій для зберігання:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Логічні резервні копії баз даних, які передаються безпосередньо в object storage і шифруються під час передавання:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Для відновлення важливі дві властивості другого варіанта. Резервна копія ніколи не потрапляє на хост бази даних — вона передається у сховище в міру того, як pg_dump її створює, тому не залежить від того самого диска, з якого походить. А дамп, який завершується з ненульовим кодом або створює нуль байтів, видаляється й позначається як невдалий, а не залишається у списку та виглядає як резервна копія.

Сьогодні Dockup не запускає безперервне архівування замість вас. Якщо вашому RPO справді потрібні хвилини, про це варто знати до ухвалення рішення. Таке архівування цілком можна самостійно налаштувати для managed database, використовуючи платформу для всього іншого.

Вправа, яку варто виконати цього тижня

Запишіть два числа для вашої production-бази даних:

1. RPO — скільки даних ви можете втратити. Вимірюється часом.
2. RTO — як довго система може бути недоступною. Також вимірюється часом.

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

Поширені запитання

У чому різниця між RPO та RTO? RPO — це обсяг утрачених даних: проміжок між останнім доступним для відновлення моментом і збоєм. RTO — час, необхідний для відновлення. Snapshot дають великий RPO і короткий RTO, а PITR працює навпаки.

Чи можна відновити рядки, видалені годину тому, з нічного snapshot? Ні. Snapshot відновлює стан на момент створення. Усе, що було записано після цього, у файлі відсутнє. Для відновлення довільного моменту потрібне безперервне архівування.

Чи є snapshot тому тим самим, що й резервна копія бази даних? Ні. Snapshot фіксує диск, зокрема стан бази даних у момент виконання запису. Логічний дамп є внутрішньо узгодженим і portable для інших версій та провайдерів. Для більшості production-конфігурацій потрібні обидва варіанти.

Як довго слід зберігати резервні копії? Достатньо довго, щоб встигнути виявити проблему. Пошкодження даних або невдалу міграцію часто виявляють через кілька днів, тому зберігання копій лише за один день часто означає, що всі наявні резервні копії вже містять пошкодження.