PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Skąd mam wiedzieć, czy moja kopia zapasowa PostgreSQL jest dobra?

Kopie zapasowe są niezbędne we wszystkich planach odzyskiwania po awarii. Może to nie zawsze wystarczyć do zagwarantowania akceptowalnego celu punktu odzyskiwania, ale jest dobrym pierwszym podejściem. Problem polega na tym, co się stanie, jeśli w przypadku awarii musisz użyć tej kopii zapasowej, która z jakiegoś powodu nie nadaje się do użytku? Prawdopodobnie nie chcesz być w takiej sytuacji, więc na tym blogu zobaczymy, jak sprawdzić, czy twoja kopia zapasowa jest dobra w użyciu.

Typy kopii zapasowych PostgreSQL

Zacznijmy rozmawiać o różnych typach kopii zapasowych. Istnieją różne typy, ale ogólnie możemy podzielić je na dwie proste kategorie:

  • logiczne :Kopia zapasowa jest przechowywana w formacie czytelnym dla człowieka, takim jak SQL.
  • Fizyczne :Kopia zapasowa zawiera dane binarne.

Dlaczego o tym wspominamy? Ponieważ zobaczymy, że jest kilka sprawdzeń, które możemy wykonać dla jednego typu, a nie dla drugiego.

Sprawdzanie dzienników kopii zapasowych

Pierwszym sposobem sprawdzenia, czy wszystko pójdzie dobrze, jest sprawdzenie dzienników kopii zapasowych.

Najprostszym poleceniem do uruchomienia kopii zapasowej PostgreSQL może być na przykład:

$ pg_dumpall > /path/to/dump.sql

Ale skąd mam wiedzieć, czy wystąpił błąd podczas działania polecenia? Możesz po prostu dodać, aby wysłać dane wyjściowe do określonego pliku dziennika:

$ pg_dumpall > /path/to/dump.sql > /var/log/postgres/pg_dump.log

Możesz więc dodać tę linię do crona serwera, aby uruchamiać go codziennie:

30 0 * * * pg_dumpall > /path/to/dump.sql > /var/log/postgres/pg_dump.log

I powinieneś monitorować plik dziennika w poszukiwaniu błędów, na przykład dodając go do jakiegoś narzędzia monitorującego, takiego jak Nagios.

Sprawdzenie dzienników nie wystarczy, aby potwierdzić, że kopia zapasowa będzie działać, ponieważ na przykład, jeśli plik kopii zapasowej jest z jakiegoś powodu uszkodzony, prawdopodobnie nie zobaczysz tego w pliku dziennika.

Sprawdzanie zawartości kopii zapasowej

Jeśli używasz logicznych kopii zapasowych, możesz zweryfikować zawartość pliku kopii zapasowej, aby potwierdzić, że masz tam wszystkie bazy danych.

Możesz wyświetlić listę swoich aktualnych baz danych PostgreSQL, używając na przykład tego polecenia:

$ psql -l | awk '{ print $1 }'| awk 'FNR > 3' |grep '^[a-zA-Z0-9]' |grep -v 'template0'

postgres

template1

world

I sprawdź, jakie bazy danych masz w pliku kopii zapasowej:

$ grep '^[\]connect' /path/to/dump.sql |awk '{print $2}'

template1

postgres

world

Problem z tym sprawdzaniem polega na tym, że nie sprawdzasz rozmiaru ani danych, więc może dojść do utraty danych, jeśli wystąpił błąd podczas wykonywania kopii zapasowej.

Przywracanie w celu ręcznego sprawdzenia kopii zapasowej

Najbezpieczniejszym sposobem sprawdzenia, czy kopia zapasowa działa, jest jej przywrócenie i dostęp do bazy danych.

Po zakończeniu tworzenia kopii zapasowej możesz ją przywrócić ręcznie na innym hoście, kopiując plik zrzutu i uruchamiając na przykład:

$ psql -f /path/to/dump.sql postgres

Następnie możesz uzyskać do niego dostęp i sprawdzić bazy danych:

$ 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)

Problem z tą metodą polega oczywiście na tym, że należy ją uruchomić ręcznie lub znaleźć sposób na zautomatyzowanie tego, co może być czasochłonnym zadaniem.

Automatyczna weryfikacja kopii zapasowej ClusterControl

Teraz zobaczmy, jak ClusterControl może zautomatyzować weryfikację kopii zapasowych PostgreSQL i pomóc uniknąć niespodzianek lub zadań ręcznych.

W ClusterControl wybierz klaster i przejdź do sekcji „Kopia zapasowa”, a następnie wybierz „Utwórz kopię zapasową”.

Funkcja automatycznej weryfikacji kopii zapasowej jest dostępna dla zaplanowanych kopii zapasowych. Wybierzmy więc opcję „Zaplanuj kopię zapasową”.

Podczas planowania kopii zapasowej, oprócz wybrania typowych opcji, takich jak metoda lub pamięć, należy również określić harmonogram/częstotliwość.

W następnym kroku możesz skompresować i zaszyfrować kopię zapasową oraz określić Okres przechowywania. Tutaj masz również funkcję „Zweryfikuj kopię zapasową”.

Aby korzystać z tej funkcji, potrzebujesz dedykowanego hosta (lub maszyny wirtualnej), nie jest częścią klastra.

ClusterControl zainstaluje oprogramowanie i przywróci kopię zapasową na tym hoście . Po przywróceniu zobaczysz ikonę weryfikacji w sekcji ClusterControl Backup.

Wnioski

Jak wspomnieliśmy, kopie zapasowe są obowiązkowe w każdym środowisku, ale kopia zapasowa nie jest kopią zapasową, jeśli nie możesz jej użyć. Dlatego upewnij się, że kopia zapasowa jest przydatna na wypadek, gdyby pewnego dnia była potrzebna. W tym blogu pokazaliśmy różne sposoby sprawdzania kopii zapasowej, aby uniknąć problemów, gdy chcesz ją przywrócić.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Wypełnianie pola Many2many (odoo 8)

  2. Odejmij godziny od funkcji now()

  3. Ograniczenie sprawdzania PostgreSQL dla warunku klucza obcego

  4. Analiza porównawcza zarządzanych rozwiązań chmurowych PostgreSQL — część pierwsza:Amazon Aurora

  5. niekompletne informacje z zapytania na pg_views