W pierwszej części tego bloga Jonathan wyjaśnił, jak działa polecenie barman-wal-archive. Teraz, zakładając, że postępowałeś zgodnie z tymi instrukcjami, masz poprawnie skonfigurowaną instancję PostgreSQL działającą i działającą. W tej drugiej części pokażę, jak barman-cloud-backup polecenie działa.
Jak można się domyślić z samej nazwy polecenia, barman-cloud-backup polecenie umożliwia wykonywanie kopii zapasowych bezpośrednio z serwera PostgreSQL i używanie jako miejsca docelowego magazynu obiektów kompatybilnego z S3 w chmurze.
example@sqldat.com:~ $ barman-cloud-backup --help
usage: barman-cloud-backup [-V] [--help] [-v | -q] [-P PROFILE] [-z | -j]
[-e {AES256,aws:kms}] [-t] [-h HOST] [-p PORT]
[-U USER] [--immediate-checkpoint] [-J JOBS]
[-S MAX_ARCHIVE_SIZE] [--endpoint-url ENDPOINT_URL]
destination_url server_name
This script can be used to perform a backup of a local PostgreSQL instance and
ship the resulting tarball(s) to the Cloud. Currently only AWS S3 is supported.
positional arguments:
destination_url URL of the cloud destination, such as a bucket in AWS
S3. For example: `s3://bucket/path/to/folder`.
server_name the name of the server as configured in Barman.
optional arguments:
-V, --version show program's version number and exit
--help show this help message and exit
-v, --verbose increase output verbosity (e.g., -vv is more than -v)
-q, --quiet decrease output verbosity (e.g., -qq is less than -q)
-P PROFILE, --profile PROFILE
profile name (e.g. INI section in AWS credentials
file)
-z, --gzip gzip-compress the WAL while uploading to the cloud
-j, --bzip2 bzip2-compress the WAL while uploading to the cloud
-e {AES256,aws:kms}, --encryption {AES256,aws:kms}
Enable server-side encryption for the transfer.
Allowed values: 'AES256'|'aws:kms'.
-t, --test Test cloud connectivity and exit
-h HOST, --host HOST host or Unix socket for PostgreSQL connection
(default: libpq settings)
-p PORT, --port PORT port for PostgreSQL connection (default: libpq
settings)
-U USER, --user USER user name for PostgreSQL connection (default: libpq
settings)
--immediate-checkpoint
forces the initial checkpoint to be done as quickly as
possible
-J JOBS, --jobs JOBS number of subprocesses to upload data to S3 (default:
2)
-S MAX_ARCHIVE_SIZE, --max-archive-size MAX_ARCHIVE_SIZE
maximum size of an archive when uploading to S3
(default: 100GB)
--endpoint-url ENDPOINT_URL
Override default S3 endpoint URL with the given one
Teraz, gdy mamy jaśniejszy obraz polecenia i jego opcji, jesteśmy gotowi do wykonania naszej pierwszej kopii zapasowej w chmurze:
example@sqldat.com:~ $ barman-cloud-backup -P barman-cloud \ -e AES256 -j --immediate-checkpoint -J 4 \ s3://barman-s3-test/ pg12
Po pomyślnym zakończeniu tworzenia kopii zapasowej base katalog zawierający kopię zapasową będzie w Twoim zasobniku S3. Sprawdźmy to, budując ścieżkę docelową z nazwą serwera i base katalog:
example@sqldat.com:~ $ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/base/
PRE 20200713T120856/
Alternatywnie możesz użyć barman-cloud-backup-list , ale w tym artykule chciałbym skupić się na mechanice, która za tym stoi.
20200711T092548 katalog zawiera wszystkie pliki związane z kopią zapasową, którą właśnie wykonaliśmy. Spójrzmy na jego zawartość:
example@sqldat.com:~ $ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/base/20200713T120856/ 2020-07-13 12:09:08 1138 backup.info 2020-07-13 12:09:07 9263096 data.tar.bz2
Jak widać, istnieje skompresowany i zaszyfrowany plik zawierający naszą kopię zapasową (data.tar.bz2 ) i plik o nazwie backup.info zawierające informacje związane z kopią zapasową. Możemy przywrócić kopię zapasową, kopiując i rozpakowując data.tar.bz2 plik na naszym lokalnym serwerze, jak pokazano poniżej:
example@sqldat.com:~ $ aws s3 --profile barman-cloud cp s3://barman-s3-test/pg12/base/20200713T120856/data.tar.bz2 restore-dir download: s3://barman-s3-test/pg12/base/20200713T120856/data.tar.bz2 to restore-dir/data.tar.bz2 example@sqldat.com:~ $ cd restore-dir example@sqldat.com:~/restore-dir $ tar xjvf data.tar.bz2 example@sqldat.com:~/restore-dir $ ls PG_VERSION conf.d pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.conf backup_label data.tar.bz2 pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact base global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf
Świetny! Jak widać, wszystkie pliki w DATADIR instancji PostgreSQL, których kopię zapasową utworzyliśmy, w tym pliki konfiguracyjne, są tutaj poprawnie wymienione.
Wnioski
Dzięki barman-cloud-backup polecenie Barman wprowadza ważną funkcję, która umożliwia wykonywanie i bezpośrednie przesyłanie kopii zapasowych bazy z lokalnego serwera PostgreSQL do usług przechowywania obiektów w chmurze, które są kompatybilne z AWS S3 w zaledwie kilku prostych krokach. Obsługuje szyfrowanie, równoległe przesyłanie, kompresję i pozwala zaoszczędzić miejsce na dysku na lokalnym serwerze i bezpiecznie przesyłać kopie zapasowe do chmury.
Wraz z wydaniem Barman 2.11 , co miało miejsce kilka dni temu, wprowadzono ważne nowe funkcje, w tym barman-cloud-wal-restore i barman-cloud-restore polecenia, które pozwalają na pobranie kopii zapasowej i plików WAL ze składnicy obiektów, takiej jak AWS S3. W związku z tym wkrótce opublikujemy nowy artykuł na blogu wyjaśniający, jak przygotować odzyskiwanie instancji PostgreSQL za pomocą tych poleceń. Bądź na bieżąco.
