KeyHelp Community

Hallo zusammen,

ich bin mir unsicher, ob ich etwas verkehrt mache (= suboptimal konfiguriere), missverstanden habe oder ob ich ggf. einen Feature-Wunsch habe:

Vorbemerkung:
Das "neue" Backup-System mit Restic ist ja in jeder Hinsicht der Hammer und ich finde es 9999 mal Besser als den veralteten Ansatz. Aber vll. habe ich ja eine Idee für Optimierung...

Situation:
Seit ein paar Tagen (< 3 Wochen) und seit ich meine ersten Kunden "komplett" nach KeyHelp migriert habe, stelle ich fest, dass das E-Mail-Backup meine Backup-Repos aufbläht.

Details:

• Jede Nacht lasse ich von meinen Kunden Vollbackups auf verschiedene Backup-Instanzen laufen und dabei fiel mir erst vor kurzem auf, dass sich das Backup-Volumen per Backup-Lauf signifikant vergrößert hat.
• Das tritt allerdings nur dann auf, wenn ich die E-Mailboxen mit sichere und nicht, wenn ich nur die Websites sichere.
• Früher hatte ich dieses Szenario noch nicht, weil ich bisher immer das Mailhosting "woanders" gemacht habe und erst seit Kurzem (1. KeyHelp-Pro-Instanz) komplett alles auf einem Server habe.
• Nachdem ich mir mal den Backup-Vorgang "live" angesehen und dann in die Snapshots geschaut hatte, fiel mir auf, dass die Mailbox-Sicherungen erstmal als TGZ erfolgen in einen Unterordner ( > /backup-keyhelp/root/[NUMMER]_[YYYYMMDD]_[hhmmss]_[irgend eine Nummer]/__email_accounts__ erfolgen.
  Und xtrahiert man die TGZ, dann findet man - logischerweise - für jede Mailbox das ganze Dovecot-Gerümpel, sprich die Maildirs mit dem eigentlichen Mailcontent. Muss ja auch so sein.
• Falls ich jetzt keinen Denkfehler gemacht habe, dann muss das Aufblähen des Repos zwingend daher kommen, dass infolge der jeweils neuen E-Mails sich das TGZ-Archiv pro Mailbox ändert und darum auch von restic unmöglich dedupliziert werden kann.

Schlussfolgerung:

• Müsste nicht die Mailbox-Sicherung so erfolgen, dass auch bei den E-Mails restic deduplizieren kann?
• Könnte man das ggf. so angehen, dass
  a) die Sicherung statt mit TAR mit einem lokalen RSYNC (ggf. auch mit Hardlinks, falls Backup-Vorlage und Quelle auf demselben FS liegen) erfolgt,
  b) anschließend ein Kompressionslauf über alle Dateien (z.B. mit "bzip2 -1" o.ä.) erfolgt, der - wenn ich es richtig in Erinnerung habe und meine Schnelltests sauber waren - immer gleich komprimiert,
  c) damit dann zwar durch die Kompression ebenfalls immer wieder CPU-Zeit verbrannt wird, aber durch die identischen Einzeldateien per Snapshot im Repo dramatisch Speicherplatz eingespart würde?
• Was ich hierbei nicht durchdacht und erst recht nicht vertestet habe mangels Möglichkeiten ist der Punkt, wie sich "mein Ansatz" auf die Backup-Laufzeit auswirkt, wenn man auf das Archiv der vielen einzelnen Maildateien verzichtet. Da könnte ich mir vorstellen, dass ein mögliches Laufzeit-Problem das Speicherplatzproblem "überlagert" bzw. die aktuell ja rel. kurze Laufzeit auch bei Remote-Backups mit rclone stark ansteigt.
  Eventuell probiere ich das mit einem Testkunden (mein eigener Kram) mal aus; ich habe immerhin 1,5 GB an komprimierten Maildaten...

Was meint ihr zu diesem PoC?
Falls ich alles richtig durchblicke und das ein Featurewunsch ist, bitte ich die Admins/Mods den Thread zu verschieben...

Vielleicht hattet ihr ja schon in dieser Richtung ähnliche Gedanken.

Viele Grüße und gute N8,
Ciao, Klaus

Hier gehts weiter:
viewtopic.php?t=12438