PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Как да разбера дали резервното ми копие на PostgreSQL е добро?

Резервните копия са задължителни във всички планове за възстановяване след бедствие. Може да не винаги е достатъчно, за да гарантира приемлива цел за точка на възстановяване, но е добър първи подход. Проблемът е какво се случва, ако в случай на неуспех трябва да използвате този архив и той не може да се използва по някаква причина? Вероятно не искате да сте в тази ситуация, така че в този блог ще видим как да потвърдим дали резервното ви копие е добро за използване.

Типове резервни копия на 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.

Заключение

Както споменахме, архивирането е задължително във всяка среда, но архивирането не е резервно копие, ако не можете да го използвате. Така че трябва да се уверите, че резервното ви копие е полезно, в случай че някой ден ви потрябва. В този блог показахме различни начини да проверите архива си, за да избегнете проблеми, когато искате да го възстановите.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Тригер срещу ограничение за проверка

  2. Как да добавите автоматично увеличаващ се първичен ключ към съществуваща таблица в PostgreSQL?

  3. Как да променя позицията на колона в таблица с база данни на PostgreSQL?

  4. Как да отмените завъртане на таблица в PostgreSQL

  5. задайте празна парола за потребител на PostgreSQL