Backup - langfristiges Sichern zusätzlich

[technotravel]

Beim Backup lässt sich ja derzeit nur die Anzahl der Backups im Repository einstellen. Da muss man dann eine Balance finden zwischen Sicherheit und Größe der Backup Dateien auf der Platte/Cloud.

Ich fände es toll, wenn es eine Option gäbe, etwa nach dem Schema: tägliches Backup, aber das letzte Backup des Monats wird nicht gepurged (und idealerweise auch nicht mitgezählt). So hätte man für kurzfristige Restores eine Lösung, aber auch ältere Backups noch zur Verfügung (könnte sich ja gelegentlich auch als nützlich erweisen).

Die Dateistruktur eines Restic Repositories scheinen mir keine Möglichkeiten zu bieten, dieses Szenario durch ein Skript zu bewerkstelligen.

Natürlich könnte man denselben Backup-Job auch nochmals anlegen, für monatlich (oder gar jährlich) - aber dann wird die Liste der geplanten Backups sowie der Repositories doch sehr lang ... Außerdem wäre es cooler, das extra monatliche/jährliche Backup beim Restore im selben Repository vorzufinden.

[OsmanAYT]

Das kannst du theoretisch jetzt ja schon umsetzen. Repo doppelt anlegen und 2 Zeitpläne. Das eine mit Standard. Das andere in dem Repo in einem anderen Ordner, was dann wöchentlich oder monatlich gemacht wird.

[Alexander]

Ich handhabe es so:

Ich hab ein Repo für tägliche Backups genannt "Backup - Täglich"
und eines für wöchentliche Backups "Backup - Wöchentlich"
(Optional, wenn für dich praktikabel noch "Backup - Monatlich" etc.)

Dann hab ich noch ein zusätzliches für manuelle Backups - für kurz mal eben was Testen und im Bedarfsfall Backup zurück spielen - "Backup - Manuell"

Alle kann ich vom Umfang, der geplanten Startzeit und der maximal aufzuhebenden Snapshots beliebig konfigurieren.

Das ist in meinen Augen viel flexibler und hat weniger Komplexität (für UI, Code, etc.) als die gewünschten Optionen.

---

Tipp, wenn du im großen Stil Platz sparen willst:
Den Haken bei E-Mail-Konten raus und unter "Dateien & Verzeichnisse" dieses Verzeichnis angeben: /var/mail/vhosts/
Damit entfällt das Vorbereiten der E-Mail-Konten (spart Zeit) und weil die inkrementelle Sicherung hier voll zum Tragen kommt, spart es Speicherplatz (und Zeit).
Das Restoren von E-Mail-Konten wird ein wenig benutzerunfreundlicher, aber das sollte verschmerzbar sein. Kann durchaus sein, das ich mit KeyHelp diesen Weg irgendwann mal als Standard etabliere (dann natürlich mit benutzerfreundlicherem Email-Restore).

[technotravel]

Das ist in meinen Augen viel flexibler und hat weniger Komplexität (für UI, Code, etc.) als die gewünschten Optionen.

Recht hast du. Werde auch so ähnlich verfahren dann. Danke.

Tipp, wenn du im großen Stil Platz sparen willst:
Den Haken bei E-Mail-Konten raus und unter "Dateien & Verzeichnisse" dieses Verzeichnis angeben: /var/mail/vhosts/
Damit entfällt das Vorbereiten der E-Mail-Konten (spart Zeit) und weil die inkrementelle Sicherung hier voll zum Tragen kommt, spart es Speicherplatz (und Zeit).
Das Restoren von E-Mail-Konten wird ein wenig benutzerunfreundlicher, aber das sollte verschmerzbar sein. Kann durchaus sein, das ich mit KeyHelp diesen Weg irgendwann mal als Standard etabliere (dann natürlich mit benutzerfreundlicherem Email-Restore).

Das mache ich schon ne Weile so (ohne zu wissen, dass es Zeit und Platz spart). Wäre gut, wenn das KH-Standard würde

In dem Zusammenhang dann ein anderer Funktionswunsch für Backup/Restore: es wäre toll, wenn man nicht bloss die Mails sichern könnte, sondern gleichzeitig (oder gesondert) die Settings der Postfächer. Es ist so unglaublich mühsam und zeitraubend, bei der Einrichtung eines neuen Servers die Email-Adressen erst händisch bei jedem Nutzer einzeln wiederherstellen zu müssen, samt Alias oder Forwarding, bevor man den Restore starten kann.

Das ist ein echtes "added value" bei der Nutzung des Server-Umzugs (wo das hervorragend funktioniert) - welches aber seinerseits keine Adaptationen in der Nutzer-Struktur zulässt. Wird halt zuverlässig alles komplett übertragen.

Da das Server-Umzug Skript ja wg Lizenz ein PRO-Feature ist, könnte ja diese Funktion (und vielleicht auch für andere Setting Backups) eine PRO Funktion werden

[kroerig]

Das eingesetzte Restic kann das eigentlich (wie Borg) von Haus aus:
https://restic.readthedocs.io/en/stable ... o-a-policy

Das müsste nur konfigurierbar gemacht werden.

[technotravel]

Habe in letzter Zeit viel mit Repos und Backups gearbeitet und wollte noch mal auf das Thema zurückkommen.

Der von Alex vorgeschlagene Workaround mit unterschiedlichen Repos für tägliche/wöchentliche/monatliche Backups funktioniert zwar, hat aber doch einige Nachteile. Abgesehen von einer erheblich längeren Liste an Repos und Backup-Jobs verdoppelt diese Methode halt auch den Speicherbedarf im Backup Medium, weil der Gewinn durch die inkrementelle Sicherung wegfällt.

Das eingesetzte Restic kann das eigentlich (wie Borg) von Haus aus:
https://restic.readthedocs.io/en/stable ... o-a-policy

Das müsste nur konfigurierbar gemacht werden.

Von daher wäre es toll, wenn diese Funktion in das Keyhelp Backup eingebaut werden könnte

[blickgerecht]

Wir nutzen für täglich, wöchentlich, monatlich auch eigene Repos. Wenn es da eine bessere Möglichkeit gäbe, wär das natürlich toll!

[tab-kh]

Ich wüsste jetzt nicht, inwiefern eine andere Möglichkeit besser sein sollte. Eine ebenso sichere Methode sollte ebenso keine wöchentlichen Backups als erforderliche Zwischenstände der täglichen Backups nutzen. Und falls doch, müssen diese spätestens dann separat gespeichert werden, wenn sie aus dem durch die täglichen, inkrementellen Backups abgedeckten Zeitraum raus sind.

Aber klar, wenn sowas doch möglich wäre, also weniger benötigter Speicherplatz bei gleicher Sicherheit und Zeitdauer des Backups, dann immer gern.