PostgreSQL бекап није проверен док се база стварно не врати

PostgreSQL резервну копију проверите тако што ћете је вратити у одвојен кластер, довршити WAL опоравак и упитима потврдити да су потребни подаци доступни. Забележите до које је тачке база стигла и колико је трајало да прихвати договорене критичне упите: успешна команда за израду бекапа не даје та два одговора.

Овај поступак важи за физичку копију направљену помоћу pgBackRest-а. Документација PostgreSQL-а разликује SQL извоз, копију система датотека и континуирано архивирање; повратак на одређени тренутак захтева копију и одговарајући низ архивираних WAL сегмената.

Изаберите копију и циљ опоравка

Пре теста запишите назив stanza конфигурације, репозиторијум, ознаку копије и сценарио: враћање до краја доступног WAL низа после симулираног губитка сервера или повратак на време пре погрешне измене података. Команда pgbackrest info --stanza=STANZA приказује копије, време њиховог почетка и завршетка и WAL опсег потребан за њихово враћање. Ако бирате копију за опоравак по времену, она мора да буде завршена пре циљног тренутка.

Циљно време узмите из познате контролне трансакције или догађаја, са временском зоном и што прецизнијим временским записом. Упутство pgBackRest-а приказује враћање помоћу --type=time и --target и показује да опоравак од погрешно изабране, новије копије не може да се врати уназад. Ако ознаку копије не задате, pgBackRest може сам да изабере копију за временски циљ; изабрану ознаку ипак сачувајте у записнику да би тест био поновљив.

Одвојите тест од продукције

Припремите засебан хост или изоловану виртуелну машину, празан одредишни директоријум и довољно простора и за податке и за WAL опоравак. Најчистија граница је локална копија или снимак репозиторијума који садржи изабрану копију, све копије од којих она зависи и WAL сегменте до циљне тачке. Тестни pgBackRest конфигуришите да чита тај репозиторијум, без мрежног приступа продукционом репозиторијуму; ако користите приступ оригиналном репозиторијуму, ограничите га на читање док се опоравак не заврши.

Пре враћања проверите да pg1-path показује искључиво на тестни директоријум и да конфигурација не упућује на продукциони PostgreSQL хост. Посебне tablespace директоријуме пресликајте на тестне путање, јер би подразумеване путање могле да буду неприкладне на другом хосту. За покретање припремите одвојен сокет или порт и ограничите мрежу тако да се апликације и репликациони клијенти не повежу са тестним кластером.

Вратите копију и довршите WAL опоравак

Следећи образац је за PostgreSQL 12 и новији: референца команди pgBackRest-а описује --set, временски циљ, мапирање tablespace директоријума и --archive-mode=off, који је доступан од те верзије. Симболичке вредности замените својим; број репозиторијума мора да одговара провереној тестној конфигурацији.

1. Зауставите тестни PostgreSQL и потврдите да је одредишни директоријум празан. Не користите --force или --delta да бисте заобишли проверу одредишта: погрешна путања тада може да доведе до преписивања постојећих података.
2. За временски циљ покрените pgbackrest --stanza=STANZA --repo=1 --set=OZNAKA --pg1-path=/srv/pg-restore --type=time --target='YYYY-MM-DD HH:MM:SS+00' --target-action=promote --archive-mode=off restore. Ако копија има tablespace директоријуме, додајте одговарајући --tablespace-map или --tablespace-map-all.
3. Пре покретања базе прегледајте подешавања која је restore уписао у postgresql.auto.conf, посебно restore_command, циљ опоравка и евентуалну везу ка примарном серверу. Потврдите да ће archive-get читати из тестног репозиторијума. Покрените PostgreSQL са тестним мрежним подешавањима и пратите дневник до достизања циља и завршетка опоравка.

Команда restore враћа датотеке, док PostgreSQL при покретању примењује потребан WAL. Зато завршетак прве команде још није успех целог теста. Ако дневник покаже да је опоравак стао пре задатог циља, забележите неуспех и проверите избор копије и непрекинутост WAL низа; покретање базе на некој другој тачки није исти резултат.

Потврдите да су подаци употребљиви

После промоције повежите се преко тестног сокета и извршите SELECT pg_is_in_recovery();. За кластер који је завршио опоравак и промовисан је очекује се false. Затим проверите да постоје потребне базе, шеме и табеле и да налог којим би се посао наставио може да изврши критичне упите. Само успешно повезивање не показује да су тражени редови враћени.

За сваку важну табелу унапред одредите проверљиву вредност: идентификатор потврђено уписаног реда, очекивани опсег броја редова или пословно смислен агрегат. Код намерног повратка на ранији тренутак користан је пар контролних трансакција: ред уписан пре циља треба да буде видљив, а ред уписан после њега не треба. Та провера показује и да је табела читљива и да је опоравак стао на планираној страни границе.

Измерите RPO и RTO и сачувајте записник

Постигнути RPO процените као размак између времена симулираног инцидента и последње потврђене контролне или пословне трансакције која је видљива у враћеној бази. Ако није било трансакција близу инцидента, тај размак је конзервативна процена старости проверених података, а не тачан доказ колико је података изгубљено. За намерни повратак на ранију тачку поредите резултат са RPO циљем тог сценарија, јер су касније трансакције свесно изостављене.

Постигнути RTO мерите од унапред одређеног почетка пробног инцидента до тренутка када тестна база прихвати договорене критичне упите. Укључите припрему окружења ако би она била неопходна и у стварном опоравку. Одвојено забележите трајање копирања датотека, примене WAL-а и SQL провере: то открива где је време потрошено, док укупно трајање остаје упоредиво са договореним RTO циљем.

Записник нека садржи сценарио, циљно време и зону, stanza и ознаку копије, путању тестног одредишта, начин изолације репозиторијума, време почетка и краја сваке фазе, поруке о достигнутој тачки опоравка и резултате контролних упита. Упишите израчунате RPO и RTO, њихове унапред договорене границе и исход за сваки критеријум. Следећи тест тада може да понови исте услове и покаже да ли се опоравак и даље завршава у потребном року, са потребним подацима.

Прочитајте и:

• Повезивање на СЕФ API: кључ није довољан док статус не постане активан
• OneByZero добио 20 милиона долара — раст прихода још није независно проверен
• Backup против рансомвера: стално повезана копија није довољна