Für Sicherungsarbeiten wurde ein Container hinzugefügt. Die hinzugefügten Container sind in der folgenden Tabelle aufgeführt. postgres-db und cron-backup teilen sich einen DB-Bereich. PITR ist einsatzbereit.
| Containername | Überblick |
|---|---|
| cron-backup | Coolon-Container zur Sicherung |
| postgres-db | PostgreSQL DB |
| pleasanter-web | Pleasanter Web System |
Das für den automatischen Sicherungsmechanismus verwendete Skript lautet wie folgt. Diese Skripte werden im pcron-backup-Container bereitgestellt.
| Skriptname | Überblick |
|---|---|
| /var/backup_sh/pg_rman.sh | Führen Sie PITR aus |
| /var/backup_sh/pg_dumpall.sh | Führen Sie die vollständige Sicherung aus |
| /var/backup_sh/pg_dumpall.sh | Führen Sie eine S3-Synchronisation durch |
Die folgende Tabelle zeigt die Verzeichnisstruktur aus Sicht des pcron-backup-Containers. Pfade, die mit 〇 geteilt werden, werden mit dem Container postgres-db geteilt.
Die Sicherungsergebnisdaten werden in "/ var / db_backup" gesammelt. Wenn Sie dieses Verzeichnis außerhalb des Containers verbinden und eine Sicherungskopie erstellen, können Sie daher eine Sicherungskopie von außerhalb des erforderlichen Containers erstellen.
| Pfadname | Überblick | Teilen zwischen Containern |
|---|---|---|
| /var/db_backup/PITR/ | Sicherungsverzeichnis für die Wiederherstellung zu einem bestimmten Zeitpunkt | |
| /var/db_backup/dumpall | Verzeichnis für alle Datensicherungen | |
| /var/backup_sh | Shell-Speicherverzeichnis für die Sicherung | |
| /var/ | Shell-Speicherverzeichnis für die Sicherung | |
| /var/lib/postgresql/data/ | postgresql Datenbereich | 〇 |
| /var/lib/postgresql/arclog | postgresql WAL Bereich | 〇 |
Das Back Operation Management wird von cron gesteuert. Die Einstellung des entsprechenden crom befindet sich in "cron-backup \ config \ crontab". Im Ausgangszustand wird es wie folgt angegeben. Bitte wechseln Sie ggf. die Zielzeit.
| Art | Frequenz |
|---|---|
| Vollständige Sicherung | Einmal täglich um 3 Uhr morgens |
| PITR(Wiederherstellung zu einem bestimmten Zeitpunkt) | Alle 30 Minuten |
Diese Sicherungsskripte werden automatisch gestartet, wenn Sie Docker Compose starten. Für den Start sind keine besonderen Maßnahmen erforderlich.
Wenn Sie im Gegenteil keine Sicherungskopie erstellen möchten, starten Sie den entsprechenden Container nicht
Wenn bisher nur die Sicherungsfunktion verwendet wird, besteht die Gefahr eines Datenverlusts, wenn der Container aufgrund eines Vorfalls fliegt. Das Backup sollte woanders aufbewahrt werden. In der heutigen Zeit gibt es eine praktische namens S3, so dass sie dort automatisch synchronisiert wird.
Es ist aktiviert, wenn die AWS CLI-Einstellung vorhanden ist. Der Pass, der das Ziel des Aktivierungsurteils ist, ist wie folgt.
「/root/.aws/config」
Es ist einfacher, diese Konfigurationsdatei außerhalb des Containers abzulegen und bereitzustellen, als sie als Konfiguration in den Container zu kopieren. (Der mit ★ unten gekennzeichnete Teil.)
docker-compose.yml
cron-backup:
build:
context: cron-backup/.
volumes:
- *APP_DB_data
- *APP_DB_arclog
#Das Ergebnis der automatischen Sicherung ist "/var/db_Es wird in "Backup" gespeichert.
#Wenn Sie von außerhalb des Containers zugreifen, platzieren Sie diesen Pfad so, dass Sie ihn von außen sehen können.
- db-backup:/var/db_backup
#Beim automatischen Sichern mit S3
#Stellen Sie aws cli auf den folgenden Pfad ein.
#Wenn es nicht existiert, wird es nicht gesichert
- ./cron-backup/config/aws-cli:/root/.aws/ ← ★
Befindet sich der Host in einer Windows-Umgebung, kann die ** Konfigurationsdatei abhängig von den GIT-Einstellungen von CRLF ** abgerufen werden. Wenn Sie die Einstellungsdatei in diesem Zustand in den Container bringen, ** stimmt der Zeilenvorschubcode nicht überein und funktioniert nicht ordnungsgemäß **. Seien Sie daher vorsichtig, wenn Sie den Zeilenvorschubcode in der Einstellungsdatei behandeln.
Zunächst müssen Sie die AWS-CLI konfigurieren. Dies ist eine allgemeine Einstellung. Rufen Sie daher die benötigten Informationen von Ihrem Konto ab.
cron-backup\config\aws-cli\credentials
[default]
aws_access_key_id =Zugangsschlüssel
aws_secret_access_key =Geheimer Schlüssel
Legen Sie als Nächstes das Sicherungsziel fest. Dies ist eine Einstellung für das Shell-Format.
cron-backup\config\aws-cli\S3Config.sh
#!/bin/bash
# ---S3-Synchronisierungseinstellungen
#S3-Bucket-Name, der synchronisiert werden soll
export S3_TARGET_BUCKET_NAME={Eimername}
#S3-Verzeichnisname, der synchronisiert werden soll
export S3_TARGET_DIRECTORY_NAME={Verzeichnisname}
Die Synchronisation mit S3 ist der Zeitpunkt, zu dem der Sicherungsprozess ausgeführt wird. Wenn die Einstellungen korrekt sind, sind keine speziellen Einstellungen erforderlich, um zu beginnen.
Die Synchronisierung mit S3 erfolgt mit der Löschoption des Befehls aws cli "rsync". Wenn dieser Befehl verwendet wird, ** entspricht das Synchronisationszielverzeichnis dem Synchronisationsquellverzeichnis **. Hier bedeutet dasselbe ** "Dateien, die sich nicht in der Synchronisationsquelle, sondern am selben Ziel befinden, werden gelöscht" **. Wenn Sie unmittelbar nach dem Erstellen einer neuen Umgebung einen Fehler in den Einstellungen machen und diese Sicherung funktioniert, gehen die erforderlichen Daten verloren und es handelt sich um ein ernstes Problem.
Daher hat der Sicherungsprozess von S3 einen abgesicherten Modus. Wenn im abgesicherten Modus andere Daten als das Sicherungssystem des vorhandenen Containers im Zielverzeichnis des Ziel-Buckets von S3 bestätigt werden, erstellen Sie ein Verzeichnis mit dem Namen "Verzeichnisname-sicher", ohne es zu überschreiben, und sichern Sie es auf dieser Seite. Es wird ein Prozess sein. Informationen zum Überprüfen der Identität des Sicherungssystems finden Sie in der Datei "BackupFiles.sha256.7z", die zum Zeitpunkt der Sicherung generiert wurde.
Grundsätzlich müssen sich Benutzer nicht zu viele Sorgen machen, aber ** achten Sie darauf, das vorhandene Backup bei der Migration in eine Umgebung nicht zu beschädigen. Überprüfen Sie nach der ersten Sicherung, ob ein Verzeichnis wie "Verzeichnisname -sicher" erstellt wurde.
In Bezug auf die Wiederherstellung Die Methode der Rückgabe hängt von der Methode zur Erfassung der Sicherungsdaten ab.
Im Folgenden wird davon ausgegangen, dass Sie im Cron-Backup-Container gearbeitet haben. Die Sicherungsdatei hat das 7z-Format und ist verschlüsselt. Bitte stellen Sie gegebenenfalls wieder her. (Den Verschlüsselungsschlüssel finden Sie in der Shell-Datei "cron-backup \ shell \ pg_dumpall.sh".) Die folgenden Befehle setzen voraus, dass die wiederhergestellte Datei den Namen "backup" trägt. Die Wiederherstellung aller Sicherungen wird mit einem einzigen Befehl unten abgeschlossen.
psql -h postgres-db -p 5432 -U postgres -f backup
PITR
Im Fall von PITR ist es etwas verwirrend. Im Fall von PITR kann es nicht gut wiederhergestellt werden, wenn postgres ausgeführt wird Starten Sie nur den Cron-Backup-Container.
docker-compose up pleasanter-cron-backup
Führen Sie in einem angenehmen Cron-Backup-Container durch. Bereiten Sie die Daten vor, die für die Wiederherstellung verwendet werden sollen. Kopieren Sie die für die Wiederherstellung verwendeten Daten nach "/ var / db_backup / PITR /".
Führen Sie in einem angenehmen Cron-Backup-Container durch. Wenn Sie Coulomb normal starten, beginnt Backup Coulomb mit der Datensicherung. Beenden Sie daher die Sicherungskühlung.
crontab -l > my_cron_backup.txt
crontab -r
Führen Sie in einem angenehmen Cron-Backup-Container durch. Der folgende Befehl zeigt eine Liste der erfassten Sicherungen an.
/usr/lib/postgresql/12/bin/pg_rman show -B /var/db_backup/PITR/
Wenn Sie den Befehl ausführen, wird eine Liste der Timings angezeigt, die als Sicherung wiederhergestellt werden können (siehe unten).
root@885777f50d56:~/out/cron-backup/shell# /usr/lib/postgresql/12/bin/pg_rman show -B /var/db_backup/PITR/
=====================================================================
StartTime EndTime Mode Size TLI Status
=====================================================================
2020-09-22 21:44:35 2020-09-22 21:44:38 INCR 33kB 3 OK
2020-09-22 21:43:32 2020-09-22 21:43:35 INCR 33kB 3 OK
2020-09-22 21:40:54 2020-09-22 21:40:58 INCR 33kB 3 OK
2020-09-22 21:39:32 2020-09-22 21:39:35 INCR 33kB 3 OK
2020-09-22 21:38:47 2020-09-22 21:38:51 INCR 33kB 3 OK
2020-09-22 21:32:47 2020-09-22 21:36:18 FULL 61MB 3 OK
Führen Sie in einem angenehmen Cron-Backup-Container durch. Im Fall von PITR gibt es zwei Muster für die Rückgabe.
Verwenden Sie den folgenden Befehl.
/usr/lib/postgresql/12/bin/pg_rman restore -B /var/db_backup/PITR/ -D /var/lib/postgresql/data/
Bei der Rückkehr zu einem beliebigen Zeitpunkt kann die Zeit für die Rückkehr angegeben werden. Der Befehl lautet wie folgt und gibt die Zielzeit als "Wiederherstellungszielzeit" an.
/usr/lib/postgresql/12/bin/pg_rman restore --recovery-target-time '2020-09-06 14:29:00' -B /var/db_backup/PITR/ -D /var/lib/postgresql/data/
Führen Sie in einem angenehmen Cron-Backup-Container durch. Stellen Sie die Coulomb-Einstellungen wieder her.
crontab my_cron_backup.txt
crontab -l
Dieser Vorgang ist gemeinsam erforderlich, unabhängig davon, ob Sie von "Alle Sicherungen" oder "PITR" zurückkehren. Während des Sicherungsprozesses werden Daten während des Systembetriebs extrahiert. Aus diesem Grund bleiben die in der Datenbank vorhandenen Sitzungsinformationen in einem halbfertigen Zustand.
Verwenden Sie den folgenden Befehl, um unnötige Daten in der Datenbank einmal zu bereinigen. (Auf dem Docker-Host ausführen.)
docker ps | grep leasanter-web | cut -d' ' -f 1 | xargs -I {} docker exec {} cmdnetcore/codedefiner.sh
Nach der Rücksendung der DB ist eine Nachbearbeitung erforderlich.
Erstellen Sie eine vollständige Sicherung, sobald Sie bestätigen, dass sie funktioniert. Sie können eine vollständige Sicherung erhalten, indem Sie den folgenden Befehl direkt ausführen. Wenn S3 eingestellt ist, wird auch die Synchronisation mit S3 ausgeführt. Seien Sie also vorsichtig.
「/var/backup_sh/pg_dumpall.sh」
Nach dem Zurücksetzen von der Sicherung hat PITR möglicherweise die Basissicherung von der zuvor vorgenommenen geändert. (In PITR wird der Unterschied der Basissicherung überlagert. Wenn jedoch die Basissicherung und der letzte DB-Status aufgrund der Wiederherstellung verloren gehen, kann der nachfolgende Sicherungsprozess nicht korrekt ausgeführt werden.) Daher muss die Basissicherung erneut abgerufen werden.
OSC Hokkaido 2014_JPUG Material Sichern Sie Mastodons PostgreSQL mit pg_rman pg_rman Versuchen Sie es mit pg_rman Einfache Sicherung und Wiederherstellung von PostgreSQL durch pg_rman