Възстановяване до определен момент срещу snapshot-и: какво губите

Някой изпълнява DELETE без клауза WHERE в 16:15 ч. Най-скорошният ви backup е от 03:00 ч. Всичко между тези два момента е изгубено и никакво възстановяване няма да го върне.

Тази разлика има име — цел за възстановяване във времето, или RPO — а решението между възстановяване до определен момент и snapshot-и изцяло зависи от това колко голяма сте готови да бъде тя.

Двата модела

Snapshot-ите запазват състоянието на данните ви в конкретен момент. Изпълняват се по график, обикновено всяка нощ. Възстановяването на snapshot ви връща точно до състоянието от момента, в който е създаден, а всичко след това се губи.

Възстановяването до определен момент комбинира базов backup с непрекъснат поток от write-ahead log на базата данни. Тъй като всяка промяна се записва по ред, можете да възпроизведете състоянието до всеки момент, покрит от запазения log — включително до 16:14 ч., една минута преди изтриването.

Разликата не е постепенна. Това е разликата между „изгубихме един ден“ и „изгубихме една минута“.

Числото, което решава

Задайте си честно един въпрос: ако изгубите всичко, записано през последните дванадесет часа, какво ще се случи?

За личен проект, документационен сайт или вътрешен инструмент, чиито данни могат да бъдат възпроизведени: не кой знае какво. Нощните snapshot-и наистина са правилният избор, а плащането за непрекъснато архивиране би било излишен разход.

За всичко, в което клиентите записват данни, отговорът обикновено е нещо от рода на „ще трябва да пишем на хората и да им обясняваме“. Поръчки, които вече не съществуват. Качени файлове, които са изчезнали. Съобщения, които са били изпратени, но вече ги няма. Само разходите за поддръжка обикновено надхвърлят разликата в инфраструктурните разходи за цяла година.

Грешката не е в избора на snapshot-и. Грешката е да ги изберете по подразбиране, без никога да се запитате колко би струвала дупка от дванадесет часа.

За какво snapshot-ите наистина са добри

Те не са по-нискокачествен продукт. Покриват повреди, с които PITR не се справя:

• Пълна загуба на диска. Snapshot на отделно хранилище възстановява всичко, включително файловете, които не се управляват от базата данни.
• Бързо, грубо връщане назад. Връщането на неуспешна миграция в staging среда е по-бързо от snapshot, отколкото чрез възпроизвеждане на log.
• Цена. Съхраняването на едно копие дневно е по-евтино от съхраняването на всеки запис.
• Простота. По-малкото движещи се части е реално оперативно предимство, особено за малък екип.

Капанът е да ги приемате за достатъчни за база данни, в която непрекъснато се записват данни.

Какво ви струва PITR

Не е безплатно и разходите си струва да бъдат назовани:

• Съхранение. Запазвате базовия backup плюс всеки запис за целия период на задържане.
• Сложност. Архивирането трябва да работи непрекъснато. Архиватор, който тихомълком не е работил цяла седмица, означава, че възстановимият ви период приключва преди седмица — затова наблюдението на архива е също толкова важно, колкото и конфигурирането му.
• Време за възстановяване. Възпроизвеждането на log отнема повече време от възстановяването на snapshot. RPO се подобрява, но RTO обикновено се влошава.

Именно последният компромис често изненадва хората. PITR означава, че губите по-малко данни, а не че се връщате онлайн по-бързо.

Слоестият отговор, от който всъщност се нуждаят повечето екипи

На практика това не е избор между две неща. За production базите данни обикновено са нужни три слоя, защото те се повреждат по три различни начина:

Snapshot-и, ежедневно, със срок на задържане от една-две седмици. Евтина застраховка срещу загуба на машината. Това покрива и файловете извън базата данни, които се намират на същия volume.

Логически dump-ове, ежедневно, съхранявани извън хоста. Един pg_dump е преносим и по конструкция е консистентен. Възстановява се върху друга major версия, при друг доставчик или на лаптоп — точно това ви е нужно, когато проблемът е в платформата, а не в данните.

Непрекъснато архивиране, когато в данните има клиенти. Слоят, който превръща „изгубихме днешния ден“ в „изгубихме една минута“.

Всеки слой покрива това, което останалите не могат. Snapshot не помага да смените доставчика. Логическият dump не помага да възстановите файл, който не е бил в базата данни. Нито един от двата не помага да отмените изтриване, извършено преди четири часа.

Къде се вписва Dockup

Dockup ви предоставя двата слоя, които покриват най-често срещаните повреди, и е важно да уточним кои са те.

Snapshot-и на volume, при поискване или по график с брой запазени копия:

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

Логически backup-и на бази данни, изпращани директно към object storage и криптирани по време на преноса:

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

Две свойства на втория вариант са важни за възстановяването. Backup-ът никога не се записва на хоста на базата данни — той се изпраща към хранилището, докато pg_dump го създава, така че не споделя съдбата на диска, от който идва. Освен това dump, който завърши с ненулев код или произведе нула байта, се изтрива и се записва като неуспешен, вместо да остане в списъка и да изглежда като backup.

Днес Dockup не изпълнява непрекъснато архивиране вместо вас. Ако RPO-то ви наистина трябва да бъде в минути, е важно да го знаете, преди да направите избор, и е напълно разумно да го изпълнявате сами спрямо управлявана база данни, докато използвате платформата за всичко останало.

Упражнението, което си струва да направите тази седмица

Запишете две числа за production базата си данни:

1. RPO — колко данни можете да загубите. Измерва се във време.
2. RTO — колко дълго можете да останете офлайн. Също се измерва във време.

След това проверете какво действително осигурява текущата ви настройка, като възстановите нещо. Ако записаните от вас числа и числата, които настройката ви осигурява, са различни, сте открили решение, което трябва да вземете, докато нищо не гори — а това е единственият добър момент да го направите.

Често задавани въпроси

Каква е разликата между RPO и RTO? RPO е колко данни губите — разликата между последния възстановим момент и повредата. RTO е колко време отнема възстановяването. Snapshot-ите ви дават голямо RPO и кратко RTO; PITR обръща това съотношение.

Мога ли да възстановя редове, изтрити преди час, от нощен snapshot? Не. Snapshot възстановява състоянието от момента, в който е създаден. Всичко, записано след това, не присъства във файла. Възстановяването на произволен момент изисква непрекъснато архивиране.

Едно и също ли са snapshot на volume и backup на база данни? Не. Snapshot запазва диска, включително състоянието, в което базата данни се е намирала по време на запис. Логическият dump е вътрешно консистентен и преносим към други версии и доставчици. Повечето production конфигурации се нуждаят и от двете.

Колко дълго трябва да задържам backup-ите? Достатъчно дълго, за да забележите проблем. Повреда или неуспешна миграция често се откриват дни по-късно, затова задържането само на един ден често означава, че единствените backup-и, с които разполагате, вече съдържат повредата.