pgBackRest und WORM

Hallo zusammen,
wir verwenden derzeit pgBackRest für die PostgreSQL Datensicherungen. Durch neue Vorgaben muss das Backup Filesystem (repo1-path) die WORM Eigenschaft bekommen.

Leider kann pgBackRest damit nicht umgehen, da in den Stanza Verzeichnissen Metadaten Dateien wie backup.info stehen. Diese werden bei jeder Sicherung erneuert und das verhindert die WORM Funktionalität. Barman scheidet deswegen leider auch aus.

Gibt es hier Alternativen oder die Möglichkeit pgBackRest (durch mir noch unbekannte Parameter) so einzustellen, dass WORM unterstützt wird. Oder noch besser, die Metadaten nicht in Dateien, sondern einer Datenbank landen?

Wie machen andere die Datenbank Sicherung, wenn WORM gefordert ist?

Ich fürchte, die Antwort ist hier „selber stricken”.
Also ein archive_command, das die WAL-Segmente auf das write-once Filesystem schreibt, und ein pg_basebackup das mit dem Backup dasselbe macht. Die Restore-Prozedur muß man dann eben händisch durchführen oder selber Scripts schreiben.

Ich habe noch nie von einer solchen Anforderung gehört, kann also nicht sagen, wie andere damit umgehen.

Danke, ich habs befürchtet.
Die Anforderung ist nicht neu, sie kommt vom BSI. Darin wird gefordert, dass ein Backup unveränderbar sein soll.

Ich vermute mal, dass die Ransomware-Angriffe der letzten Jahre hier etwas zu der Anforderung beigetragen haben.

Kannst Du das Backup nicht in ein temporäres Verzeichnis machen und danach in den WORM Speicher verschieben?

Grundsätzlich wäre sowas möglich. Ich könnte dann auch an pgBackRest festhalten, aber ganz so einfach wird das nicht. Denn in dem temporären Backup Verzeichnis laden ja auch die WAL Dateien und das können sehr viele sein. Wenn ich das jetzt zum Beispiel mit rsync in ein WORM Verzeichnis kopiere, darf ich keine “halben” Dateien erwischen. Die könnte ich ja später nicht mehr durch die vollständigen ersetzen. Auch dem könnte man entgegenwirken, in dem man nur Dateien synchronisiert, die zum Beispiel älter als 1 Minute sind.

Das mag am Ende funktionieren, aber es fühlt sich, wie Laurenz es nennt “selbst gestrickt” an. Aber wahrscheinlich wird es bei sowas ähnlichem bleiben.

  • Könnte man nicht ein Backup durch Signieren oder Speichern einer Checksumme unveränderbar machen?
  • Wenn ich eine andere write-once Platte nehme, ein verändertes Backup draufschreibe und die ursprüngliche Platte durch die gefälschte ersetzt, wie soll das verhindert werden? Ich stelle die Sinnhaftigkeit der Anforderung in Frage. Warum nicht den Backup-Server hinreichend sichern?

Mmh, selbstgestrickt ist in meinen Augen überhaupt kein Mangel. Im Gegenteil, es bedeutet vollkommene Transparenz!
Wenn der Hintergrund der Anforderung wirklich Ransomware ist, bietet eine nicht Standardlösung sogar Vorteile. Ich würde vermuten, fast alle (verbreiteten) Angriffsverfahren basieren auf Sicherheitslücken, Spuren und Vorgängen von Standardverfahren.
Natürlich muss ein selbstgebautes Verfahren reibungslos funktionieren. Dazu muss man es testen und regelmäßig auch das Rücklesen eines Backups prüfen. (Das dürfte aber vom BSI auch gefordert sein)