sia
gesperrt
Ich setze bei meinen Backups auf Syncthing in Kombination mit Borgmatic.
Syncthing synchronisiert die Live-Daten dauerhaft zwischen dem beim Klienten stehenden Edge-Server und dem Dateiserver in der Cloud™. Dort befindet sich der Syncthing-Home-Ordner auf einer mit LUKS verschlüsselten Partition. Jeder Klient ist auf einem eigenen KVM-virtualisierten Dateiserver untergebracht. Der Hypervisor entschlüsselt die Platten mittels TPMv2 und clevis.
Wenn Dateien geändert oder gelöscht werden, werden diese sowohl auf dem Quell- als auch auf dem Zielserver mit der Syncthing-eigenen "staggered file versioning"-Methode versioniert. Dabei werden abhängig vom Alter der geänderten Dateien Kopien davon aufgehoben:
Das Maximal-Alter der Syncthing-Versionierung ist hier 30 Tage. Das ist das, was die Key-User dann in einem eigenen Samba-Share namens "Papierkorb" schreibgeschützt vorfinden. Die Zugriffe auf den Papierkorb werden in einem Auditlog für Geschäftsführer und Datenschutzbeauftragte nachvollziehbar gespeichert.
Der Schreibschutz wird hier durch einen inotify-Trigger realisiert, der die neuen Dateien im Papierkorb automatisch dem Syncthing-User "wegnimmt" (chown papierkorb:users; chmod 440). Der Grund dafür ist der Schutz vor Ransomware und "rogue users", also Leuten, die beim Verlassen der Firma noch schnell ihre Dateien löschen wollen.
Alle 30min werden von den Syncthing-Shares auf dem Dateiserver mittels Borgmatic Schnappschüsse auf einen Backup-Server (ebenfalls in der Wolke) gemacht. Dieser hat keine LUKS-verschlüsselten Partitionen, um die Geschwindigkeit nicht durch doppelte Verschlüsselung zu mindern. Der PGP-Key für das Backup wird ebenfalls mittels Clevis aus dem TPM gezogen.
Das hat leider den Nachteil, dass bei langsamer Anbindung zwischen Edge- und Sync-Server nur die bereits synchronisierten Dateien gesichert werden. Im ungünstigsten Fall (Brand/Überflutung der kompletten Geschäftsräume mit noch nicht vollständig synchronisiertem Datenstand) sind dann auch Daten vom Vortag oder ein paar Tagen zuvor nicht mehr verfügbar. Die Klienten sind dazu angehalten, die allerwichtigsten Daten noch einmal manuell zu sichern.
Die Synchronisierung in Syncthing ist so eingestellt, dass die kleinsten Dateien zuerst synchronisiert werden. Meiner Erfahrung nach sind das die wichtigsten Daten. Den Verlust eines 4K-Pornos kann man notfalls noch mit erneutem Dreh kompensieren, die Excel-Tabelle der Buchhalterin zu den Konten auf den Caymans sollte allerdings baldmöglichst synchronisiert werden.
Da das Ganze Push-Backups sind und borgbackup leider noch keine Möglichkeit bietet, die Backups über Pull durchzuführen, wird nach erfolgreichem Abschluss des Backups mittels SSH-Command-Einschränkung (der Backup-User kann kein "borg delete" ausführen!) zusätzlich ein Schreibschutz über die vorherige Backupversion gelegt. Die aktuelle Backupversion muss ja noch zur Deduplikation genutzt werden können.
Die Borg-Backups werden dann ähnlich der obenstehenden Syncthing-Versionierungsstrategie folgendermaßen aufgehoben:
Diese Backups sind ebenfalls read-only für die Key-User mittels Borg-GUI abrufbar. Die monatlichen Backups werden dann pro Klient auf 1-5 Festplatten á 10TB gesichert (der größte Klient hat etwa 300TB Daten) und in einem Safe gelagert. Das passiert "round robin" über USB 3.0/TB, d.h. einmal im Monat wird die USB-Backplane automatisiert mittels Zeitschaltuhr angeschaltet, das Backup wird durchgeführt und ich tausche die Festplatten im abgeschlossenen feuerfesten Schrank aus.
Bei den kleineren Klienten ist es nur jeweils 1 Festplatte, der größte Klient hat eine Unterteilung zwischen Cold-Storage- (250TB, liegt dauerhaft im Schrank) und Hot-Storage-Backups (rotiert jeden Monat, 50TB der aktuellsten Daten). Das minimiert den Aufwand, mehrere der externen 5-Fach-Gehäuse zu tragen.
Die Speicherung der Backups selbst auf den externen Festplatten erfolgt pro Klient unterschiedlich (je nach Größe der Backups) in einem LVM2-Striping-Setup. Also kein RAID, weil teuer. Die Festplatten werden nach 25000 Betriebsstunden oder 3 Jahren auf Kosten der Klienten ausgetauscht – manche wollen das nicht zahlen, daher verwende ich dort die alten Platten und monitore stattdessen die SMART-Parameter.
Diese Backup-Strategie folgt der 3-2-1-Regel für Backups: Es gibt min. 3 Kopien der Daten (Edge-Server, Sync-Server, Backup-Server), von denen 2 verschiedene Medien genutzt werden (lokales RAID / remote RAID / Festplatten) und mindestens 1 davon "außer Haus" liegt (tatsächlich sind es 3 Kopien außer Haus: Sync-Server, Backup-Server, Festplatten).
Alle paar Monate schließe ich alle externen Gehäuse an meinen Laptop an und lasse kurz SMART und fsck.xfs drüber laufen, um zu sehen, ob noch alles "rund läuft".
Syncthing synchronisiert die Live-Daten dauerhaft zwischen dem beim Klienten stehenden Edge-Server und dem Dateiserver in der Cloud™. Dort befindet sich der Syncthing-Home-Ordner auf einer mit LUKS verschlüsselten Partition. Jeder Klient ist auf einem eigenen KVM-virtualisierten Dateiserver untergebracht. Der Hypervisor entschlüsselt die Platten mittels TPMv2 und clevis.
Wenn Dateien geändert oder gelöscht werden, werden diese sowohl auf dem Quell- als auch auf dem Zielserver mit der Syncthing-eigenen "staggered file versioning"-Methode versioniert. Dabei werden abhängig vom Alter der geänderten Dateien Kopien davon aufgehoben:
- 1 Stunde lang innerhalb der ersten Stunde
- 1 Tag lang für den ersten Tag
- 30 Tage jeden Tag des Monats
Das Maximal-Alter der Syncthing-Versionierung ist hier 30 Tage. Das ist das, was die Key-User dann in einem eigenen Samba-Share namens "Papierkorb" schreibgeschützt vorfinden. Die Zugriffe auf den Papierkorb werden in einem Auditlog für Geschäftsführer und Datenschutzbeauftragte nachvollziehbar gespeichert.
Der Schreibschutz wird hier durch einen inotify-Trigger realisiert, der die neuen Dateien im Papierkorb automatisch dem Syncthing-User "wegnimmt" (chown papierkorb:users; chmod 440). Der Grund dafür ist der Schutz vor Ransomware und "rogue users", also Leuten, die beim Verlassen der Firma noch schnell ihre Dateien löschen wollen.
Alle 30min werden von den Syncthing-Shares auf dem Dateiserver mittels Borgmatic Schnappschüsse auf einen Backup-Server (ebenfalls in der Wolke) gemacht. Dieser hat keine LUKS-verschlüsselten Partitionen, um die Geschwindigkeit nicht durch doppelte Verschlüsselung zu mindern. Der PGP-Key für das Backup wird ebenfalls mittels Clevis aus dem TPM gezogen.
Das hat leider den Nachteil, dass bei langsamer Anbindung zwischen Edge- und Sync-Server nur die bereits synchronisierten Dateien gesichert werden. Im ungünstigsten Fall (Brand/Überflutung der kompletten Geschäftsräume mit noch nicht vollständig synchronisiertem Datenstand) sind dann auch Daten vom Vortag oder ein paar Tagen zuvor nicht mehr verfügbar. Die Klienten sind dazu angehalten, die allerwichtigsten Daten noch einmal manuell zu sichern.
Die Synchronisierung in Syncthing ist so eingestellt, dass die kleinsten Dateien zuerst synchronisiert werden. Meiner Erfahrung nach sind das die wichtigsten Daten. Den Verlust eines 4K-Pornos kann man notfalls noch mit erneutem Dreh kompensieren, die Excel-Tabelle der Buchhalterin zu den Konten auf den Caymans sollte allerdings baldmöglichst synchronisiert werden.
Da das Ganze Push-Backups sind und borgbackup leider noch keine Möglichkeit bietet, die Backups über Pull durchzuführen, wird nach erfolgreichem Abschluss des Backups mittels SSH-Command-Einschränkung (der Backup-User kann kein "borg delete" ausführen!) zusätzlich ein Schreibschutz über die vorherige Backupversion gelegt. Die aktuelle Backupversion muss ja noch zur Deduplikation genutzt werden können.
Die Borg-Backups werden dann ähnlich der obenstehenden Syncthing-Versionierungsstrategie folgendermaßen aufgehoben:
- alle 30min innerhalb des ersten Tages
- täglich innerhalb des ersten Monats
- monatlich innerhalb des ersten Jahres
- Jährlich für immer™
Diese Backups sind ebenfalls read-only für die Key-User mittels Borg-GUI abrufbar. Die monatlichen Backups werden dann pro Klient auf 1-5 Festplatten á 10TB gesichert (der größte Klient hat etwa 300TB Daten) und in einem Safe gelagert. Das passiert "round robin" über USB 3.0/TB, d.h. einmal im Monat wird die USB-Backplane automatisiert mittels Zeitschaltuhr angeschaltet, das Backup wird durchgeführt und ich tausche die Festplatten im abgeschlossenen feuerfesten Schrank aus.
Bei den kleineren Klienten ist es nur jeweils 1 Festplatte, der größte Klient hat eine Unterteilung zwischen Cold-Storage- (250TB, liegt dauerhaft im Schrank) und Hot-Storage-Backups (rotiert jeden Monat, 50TB der aktuellsten Daten). Das minimiert den Aufwand, mehrere der externen 5-Fach-Gehäuse zu tragen.
Die Speicherung der Backups selbst auf den externen Festplatten erfolgt pro Klient unterschiedlich (je nach Größe der Backups) in einem LVM2-Striping-Setup. Also kein RAID, weil teuer. Die Festplatten werden nach 25000 Betriebsstunden oder 3 Jahren auf Kosten der Klienten ausgetauscht – manche wollen das nicht zahlen, daher verwende ich dort die alten Platten und monitore stattdessen die SMART-Parameter.
Diese Backup-Strategie folgt der 3-2-1-Regel für Backups: Es gibt min. 3 Kopien der Daten (Edge-Server, Sync-Server, Backup-Server), von denen 2 verschiedene Medien genutzt werden (lokales RAID / remote RAID / Festplatten) und mindestens 1 davon "außer Haus" liegt (tatsächlich sind es 3 Kopien außer Haus: Sync-Server, Backup-Server, Festplatten).
Alle paar Monate schließe ich alle externen Gehäuse an meinen Laptop an und lasse kurz SMART und fsck.xfs drüber laufen, um zu sehen, ob noch alles "rund läuft".
Zuletzt bearbeitet: