Резервните копия са задължителни във всички планове за възстановяване след бедствие. Може да не винаги е достатъчно, за да гарантира приемлива цел за точка на възстановяване, но е добър първи подход. Проблемът е какво се случва, ако в случай на неуспех трябва да използвате този архив и той не може да се използва по някаква причина? Вероятно не искате да сте в тази ситуация, така че в този блог ще видим как да потвърдим дали резервното ви копие е добро за използване.
Типове резервни копия на PostgreSQL
Нека започнем да говорим за различните видове резервни копия. Има различни видове, но като цяло можем да го разделим на две прости категории:
- Логически :Архивът се съхранява в четим от човека формат като SQL.
- Физически :Архивът съдържа двоични данни.
Защо споменаваме това? Защото ще видим, че има някои проверки, които можем да направим за един тип, а не за другия.
Проверка на архивните регистрационни файлове
Първият начин да потвърдите дали всичко е наред е като проверите архивните регистрационни файлове.
Най-простата команда за стартиране на резервно копие на PostgreSQL може да бъде например:
$ pg_dumpall > /path/to/dump.sql
Но как мога да разбера дали е имало грешка при изпълнение на командата? Можете просто да добавите, за да изпратите изхода към конкретен регистрационен файл:
$ pg_dumpall > /path/to/dump.sql > /var/log/postgres/pg_dump.log
И така, можете да добавите този ред в cron на сървъра, за да го изпълнявате всеки ден:
30 0 * * * pg_dumpall > /path/to/dump.sql > /var/log/postgres/pg_dump.log
И трябва да наблюдавате регистрационния файл, за да потърсите грешки, например, като го добавите в някакъв инструмент за наблюдение като Nagios.
Проверката на регистрационните файлове не е достатъчна, за да се потвърди, че архивирането ще работи, защото например, ако архивният файл е повреден по някаква причина, вероятно няма да го видите в регистрационния файл.
Проверка на архивното съдържание
Ако използвате логически архиви, можете да проверите съдържанието на архивния файл, за да потвърдите, че имате всички бази данни там.
Можете да изброите текущите си PostgreSQL бази данни, като използвате например тази команда:
$ psql -l | awk '{ print $1 }'| awk 'FNR > 3' |grep '^[a-zA-Z0-9]' |grep -v 'template0'
postgres
template1
world
И проверете кои бази данни имате в архивния файл:
$ grep '^[\]connect' /path/to/dump.sql |awk '{print $2}'
template1
postgres
world
Проблемът с тази проверка е, че не проверявате размера или данните, така че е възможно да имате някаква загуба на данни, ако е имало грешка при изпълнение на архивирането.
Възстановяване за ръчна проверка на архива
Най-сигурният начин да потвърдите дали архивното копие работи е възстановяването му и достъп до базата данни.
След като архивирането приключи, можете да го възстановите ръчно в друг хост, като копирате дъмп файла и стартирате например:
$ psql -f /path/to/dump.sql postgres
След това можете да получите достъп до него и да проверите базите данни:
$ psql
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
postgres | postgres | UTF8 | en_US.utf-8 | en_US.utf-8 |
template0 | postgres | UTF8 | en_US.utf-8 | en_US.utf-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.utf-8 | en_US.utf-8 | =c/postgres +
| | | | | postgres=CTc/postgres
world | postgres | UTF8 | en_US.utf-8 | en_US.utf-8 |
(4 rows)
Проблемът с този метод, разбира се, е, че трябва да го стартирате ръчно или да намерите начин да го автоматизирате, което може да отнеме време.
Автоматична проверка на архивиране на ClusterControl
Сега нека да видим как ClusterControl може да автоматизира проверката на резервни копия на PostgreSQL и да помогне за избягване на всякакви изненади или ръчни задачи.
В ClusterControl изберете своя клъстер и отидете в секцията „Резервно копие“, след което изберете „Създаване на резервно копие“.
Функцията за автоматично потвърждаване на архивиране е налична за планираните резервни копия. И така, нека изберем опцията „График за архивиране“.
Когато планирате архивиране, в допълнение към избора на общи опции като метод или съхранение, трябва също да посочите график/честота.
В следващата стъпка можете да компресирате и шифровате резервното си копие и да посочите период на задържане. Тук имате и функцията „Проверка на архивиране“.
За да използвате тази функция, имате нужда от специален хост (или VM), който не е част от клъстера.
ClusterControl ще инсталира софтуера и ще възстанови архива в този хост . След възстановяване можете да видите иконата за проверка в секцията за архивиране на ClusterControl.
Заключение
Както споменахме, архивирането е задължително във всяка среда, но архивирането не е резервно копие, ако не можете да го използвате. Така че трябва да се уверите, че резервното ви копие е полезно, в случай че някой ден ви потрябва. В този блог показахме различни начини да проверите архива си, за да избегнете проблеми, когато искате да го възстановите.