Twoje dane są prawdopodobnie najcenniejszym zasobem w firmie, dlatego powinieneś mieć plan odzyskiwania po awarii (DRP), aby zapobiec utracie danych w razie wypadku lub awarii sprzętu. Kopia zapasowa to najprostsza forma DR. Może nie zawsze wystarczyć do zagwarantowania akceptowalnego celu punktu odzyskiwania (RPO), ale jest dobrym pierwszym podejściem. Ponadto należy zdefiniować docelowy czas odzyskiwania (RTO) zgodnie z wymaganiami firmy. Istnieje wiele sposobów na osiągnięcie wartości RTO, zależy to od celów firmy.
W tym blogu zobaczymy, jak używać pgBackRest do tworzenia kopii zapasowych PostgreSQL i TimescaleDB oraz jak korzystać z jednej z najważniejszych funkcji tego narzędzia do tworzenia kopii zapasowych, kombinacji pełnych, przyrostowych i różnicowych kopii zapasowych, aby zminimalizować przestoje.
Co to jest pgBackRest?
Istnieją różne typy kopii zapasowych baz danych:
- Logiczne:kopia zapasowa jest przechowywana w formacie czytelnym dla człowieka, takim jak SQL.
- Fizyczne:kopia zapasowa zawiera dane binarne.
- Pełna/Przyrostowa/Różnicowa:Definicja tych trzech typów kopii zapasowych jest zawarta w nazwie. Pełna kopia zapasowa to pełna kopia wszystkich Twoich danych. Przyrostowa kopia zapasowa tworzy kopie zapasowe tylko tych danych, które uległy zmianie od czasu wykonania poprzedniej kopii zapasowej, a różnicowa kopia zapasowa zawiera tylko te dane, które uległy zmianie od ostatniego wykonania pełnej kopii zapasowej. Przyrostowe i różnicowe kopie zapasowe zostały wprowadzone jako sposób na zmniejszenie ilości czasu i wykorzystania miejsca na dysku potrzebnego do wykonania pełnej kopii zapasowej.
pgBackRest to narzędzie do tworzenia kopii zapasowych typu open source, które tworzy fizyczne kopie zapasowe z pewnymi ulepszeniami w porównaniu z klasycznym narzędziem pg_basebackup. Możemy użyć pgBackRest do wykonania początkowej kopii bazy danych dla Streaming Replication przy użyciu istniejącej kopii zapasowej lub możemy użyć opcji delta, aby odbudować stary serwer rezerwowy.
Niektóre z najważniejszych funkcji pgBackRest to:
- Równoległe kopie zapasowe i przywracanie
- Obsługa lokalna lub zdalna
- Pełne, przyrostowe i różnicowe kopie zapasowe
- Obrót kopii zapasowych i wygaśnięcie archiwów
- Sprawdzenie integralności kopii zapasowej
- Wznowienie kopii zapasowej
- Przywracanie Delta
- Szyfrowanie
Zobaczmy teraz, jak możemy użyć pgBackRest do tworzenia kopii zapasowych naszych baz danych PostgreSQL i TimescaleDB.
Jak korzystać z pgBackRest
W tym teście użyjemy CentOS 7 jako systemu operacyjnego i PostgreSQL 11 jako serwera bazy danych. Założymy, że masz zainstalowaną bazę danych, jeśli nie, możesz skorzystać z tych linków, aby w łatwy sposób wdrożyć zarówno PostgreSQL, jak i TimescaleDB za pomocą ClusterControl.
Najpierw musimy zainstalować pakiet pgbackrest.
$ yum install pgbackrestpgBackRest może być używany z wiersza poleceń lub z pliku konfiguracyjnego znajdującego się domyślnie w /etc/pgbackrest.conf w CentOS7. Ten plik zawiera następujące wiersze:
[global]
repo1-path=/var/lib/pgbackrest
#[main]
#pg1-path=/var/lib/pgsql/10/dataMożesz sprawdzić ten link, aby zobaczyć, który parametr możemy dodać do tego pliku konfiguracyjnego.
Dodamy następujące wiersze:
[testing]
pg1-path=/var/lib/pgsql/11/dataUpewnij się, że w pliku postgresql.conf dodano następującą konfigurację (te zmiany wymagają ponownego uruchomienia usługi).
archive_mode = on
archive_command = 'pgbackrest --stanza=testing archive-push %p'
max_wal_senders = 3
wal_level = logicalTeraz weźmy podstawową kopię zapasową. Po pierwsze, musimy utworzyć „stanzę”, która definiuje konfigurację kopii zapasowej dla określonego klastra bazy danych PostgreSQL lub TimescaleDB. Sekcja sekcji musi określać ścieżkę klastra bazy danych i hosta/użytkownika, jeśli klaster bazy danych jest zdalny.
$ pgbackrest --stanza=testing --log-level-console=info stanza-create
2019-04-29 21:46:36.922 P00 INFO: stanza-create command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:46:37.475 P00 INFO: stanza-create command end: completed successfully (554ms)Następnie możemy uruchomić polecenie check, aby sprawdzić poprawność konfiguracji.
$ pgbackrest --stanza=testing --log-level-console=info check
2019-04-29 21:51:09.893 P00 INFO: check command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:51:12.090 P00 INFO: WAL segment 000000010000000000000001 successfully stored in the archive at '/var/lib/pgbackrest/archive/testing/11-1/0000000100000000/000000010000000000000001-f29875cffe780f9e9d9debeb0b44d945a5165409.gz'
2019-04-29 21:51:12.090 P00 INFO: check command end: completed successfully (2197ms)Aby wykonać kopię zapasową, uruchom następujące polecenie:
$ pgbackrest --stanza=testing --type=full --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=full
WARN: option repo1-retention-full is not set, the repository may run out of space
HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 15:43:21": backup begins after the next regular checkpoint completes
INFO: backup start archive = 000000010000000000000006, lsn = 0/6000028
WARN: aborted backup 20190429-215508F of same type exists, will be cleaned to remove invalid files and resumed
INFO: backup file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: full backup size = 31.8MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 000000010000000000000006, lsn = 0/6000130
INFO: new backup label = 20190429-215508F
INFO: backup command end: completed successfully (12810ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (10ms)Teraz mamy kopię zapasową ukończoną z wynikiem „ukończono pomyślnie”, więc przejdźmy do jej przywrócenia. Zatrzymamy usługę postgresql-11.
$ service postgresql-11 stop
Redirecting to /bin/systemctl stop postgresql-11.serviceI pozostaw katalog danych pusty.
$ rm -rf /var/lib/pgsql/11/data/*Teraz uruchom następujące polecenie:
$ pgbackrest --stanza=testing --log-level-stderr=info restore
INFO: restore command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
INFO: restore backup set 20190429-215508F
INFO: restore file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: write /var/lib/pgsql/11/data/recovery.conf
INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
INFO: restore command end: completed successfully (10819ms)Następnie uruchom usługę postgresql-11.
$ service postgresql-11 stopA teraz mamy uruchomioną i działającą bazę danych.
$ psql -U app_user world
world=> select * from city limit 5;
id | name | countrycode | district | population
----+----------------+-------------+---------------+------------
1 | Kabul | AFG | Kabol | 1780000
2 | Qandahar | AFG | Qandahar | 237500
3 | Herat | AFG | Herat | 186800
4 | Mazar-e-Sharif | AFG | Balkh | 127800
5 | Amsterdam | NLD | Noord-Holland | 731200
(5 rows)Zobaczmy teraz, jak możemy wykonać kopię różnicową.
$ pgbackrest --stanza=testing --type=diff --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=diff
WARN: option repo1-retention-full is not set, the repository may run out of space
HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: last backup label = 20190429-215508F, version = 2.13
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 21:22:58": backup begins after the next regular checkpoint completes
INFO: backup start archive = 00000002000000000000000B, lsn = 0/B000028
WARN: a timeline switch has occurred since the last backup, enabling delta checksum
INFO: backup file /var/lib/pgsql/11/data/base/16429/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/16429/2608 (448KB, 8%) checksum 53bd7995dc4d29226b1ad645995405e0a96a4a7b
. . .
INFO: diff backup size = 40.1MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 00000002000000000000000B, lsn = 0/B000130
INFO: new backup label = 20190429-215508F_20190430-212258D
INFO: backup command end: completed successfully (23982ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (14ms)Aby uzyskać bardziej złożone kopie zapasowe, możesz postępować zgodnie z instrukcją użytkownika pgBackRest.
Jak wspomnieliśmy wcześniej, do zarządzania kopiami zapasowymi możesz użyć wiersza poleceń lub plików konfiguracyjnych.
Jak używać pgBackRest w ClusterControl
Od wersji 1.7.2 ClusterControl dodał obsługę pgBackRest do tworzenia kopii zapasowych baz danych PostgreSQL i TimescaleDB, więc zobaczmy, jak możemy go użyć z ClusterControl.
Tworzenie kopii zapasowej
W tym celu przejdź do ClusterControl -> Wybierz Cluster -> Kopia zapasowa -> Utwórz kopię zapasową.
Możemy stworzyć nową kopię zapasową lub skonfigurować zaplanowaną. W naszym przykładzie natychmiast utworzymy pojedynczą kopię zapasową.
Musimy wybrać jedną metodę, serwer, z którego zostanie pobrana kopia zapasowa i gdzie chcemy przechowywać kopię zapasową. Możemy również przesłać naszą kopię zapasową do chmury (AWS, Google lub Azure), włączając odpowiedni przycisk.
W takim przypadku wybierzemy metodę pgbackrestfull, aby wykonać początkową pełną kopię zapasową. Po wybraniu tej opcji zobaczymy następującą czerwoną notatkę:
„Podczas pierwszej próby wykonania kopii zapasowej pgBackRest, ClusterControl ponownie skonfiguruje węzeł (wdroży i skonfiguruje pgBackRest), a następnie węzeł db należy najpierw zrestartować”.
Dlatego proszę, weź to pod uwagę przy pierwszej próbie wykonania kopii zapasowej.
Następnie określamy użycie kompresji i poziom kompresji dla naszej kopii zapasowej.
W sekcji kopii zapasowej możemy zobaczyć postęp tworzenia kopii zapasowej oraz informacje, takie jak metoda, rozmiar, lokalizacja i inne.
Kroki są takie same, aby utworzyć dyferencjał przyrostowej kopii zapasowej. Musimy tylko wybrać żądaną metodę podczas tworzenia kopii zapasowej.
Przywracanie kopii zapasowej
Po zakończeniu tworzenia kopii zapasowej możemy ją przywrócić za pomocą ClusterControl. W tym celu w naszej sekcji kopii zapasowej (ClusterControl -> Wybierz Cluster -> Kopia zapasowa) możemy wybrać „Przywróć kopię zapasową” lub bezpośrednio „Przywróć” na kopii zapasowej, którą chcemy przywrócić.
Mamy trzy opcje przywrócenia kopii zapasowej. Możemy przywrócić kopię zapasową w istniejącym węźle bazy danych, przywrócić i zweryfikować kopię zapasową na samodzielnym hoście lub utworzyć nowy klaster z kopii zapasowej.
Jeśli wybierzemy opcję Przywróć na węźle, musimy określić węzeł główny, ponieważ jest to jedyny zapisywalny w klastrze.
Możemy monitorować postęp naszego przywracania w sekcji Aktywność w naszym ClusterControl.
Automatyczna weryfikacja kopii zapasowej
Kopia zapasowa nie jest kopią zapasową, jeśli nie można jej przywrócić. Weryfikowanie kopii zapasowych to coś, co zwykle jest przez wielu zaniedbywane. Zobaczmy, jak ClusterControl może zautomatyzować weryfikację kopii zapasowych PostgreSQL i TimescaleDB i pomóc uniknąć niespodzianek.
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ęć, musimy również określić harmonogram/częstotliwość.
W następnym kroku możemy skompresować naszą kopię zapasową i włączyć funkcję „Zweryfikuj kopię zapasową”.
Aby korzystać z tej funkcji, potrzebujemy dedykowanego hosta (lub maszyny wirtualnej), który nie jest częścią klastra.
ClusterControl zainstaluje oprogramowanie i przywróci kopię zapasową na tym hoście. Po przywróceniu widzimy ikonę weryfikacji w sekcji ClusterControl Backup.
Zalecenia
Istnieje również kilka wskazówek, które możemy wziąć pod uwagę podczas tworzenia kopii zapasowych:
- Przechowuj kopię zapasową w lokalizacji zdalnej:Nie powinniśmy przechowywać kopii zapasowej na serwerze bazy danych. W przypadku awarii serwera możemy jednocześnie stracić bazę danych i kopię zapasową.
- Zachowaj kopię najnowszej kopii zapasowej na serwerze bazy danych:może to być przydatne do szybszego odzyskiwania.
- Użyj przyrostowych/różnicowych kopii zapasowych:aby skrócić czas odzyskiwania kopii zapasowej i wykorzystanie miejsca na dysku.
- Utwórz kopię zapasową WAL:Jeśli musimy przywrócić bazę danych z ostatniej kopii zapasowej, jeśli tylko ją przywrócisz, utracisz zmiany od czasu wykonania kopii zapasowej do czasu przywrócenia, ale jeśli mamy WAL, możemy zastosować zmiany i możemy użyć PITR.
- Używaj zarówno kopii logicznych, jak i fizycznych:obie są potrzebne z różnych powodów, na przykład, jeśli chcemy przywrócić tylko jedną bazę danych/tabelę, nie potrzebujemy fizycznej kopii zapasowej, potrzebujemy tylko logicznej kopii zapasowej i będzie być jeszcze szybszym niż przywracanie całego serwera.
- Tworzenie kopii zapasowych z węzłów rezerwowych (jeśli to możliwe):Aby uniknąć dodatkowego obciążenia węzła podstawowego, dobrą praktyką jest pobranie kopii zapasowej z serwera rezerwowego.
- Przetestuj kopie zapasowe:Potwierdzenie, że kopia zapasowa została wykonana, nie wystarczy, aby upewnić się, że kopia zapasowa działa. Powinniśmy przywrócić go na samodzielnym serwerze i przetestować, aby uniknąć niespodzianki w przypadku awarii.
Wniosek
Jak widzieliśmy, pgBackRest to dobra opcja na ulepszenie naszej strategii tworzenia kopii zapasowych. Pomaga chronić dane i może być przydatne dotarcie do RTO poprzez skrócenie przestojów w przypadku awarii. Przyrostowe kopie zapasowe mogą pomóc w skróceniu czasu i przestrzeni dyskowej używanej do tworzenia kopii zapasowej. ClusterControl może pomóc zautomatyzować proces tworzenia kopii zapasowej baz danych PostgreSQL i TimescaleDB, a w przypadku awarii przywrócić go kilkoma kliknięciami.
