KeyHelp Community

Hallo Alex,

bitte korrigiere mich falls ich falsch liege.

Beim restic Backup werden die E-Mails zuerst in eine tar.gz Datei gepackt und dann übertragen.
Dies hängt mit der Rechtevergabe zusammen da der User keinen direkten Zugriff auf /var/mail/ hat.
Jedoch verhindert diese tar.gz Datei, dass restic effizient nur die Unterschiede abgleichen kann.
Es muss jedes Mal die gesamte Datei übertragen werden.
Ein Kunde mit 10 GB Mailspace belegt nach 10 Sicherungen 100 GB Backupspeicher.

Meine Idee:
Anstatt eine tar.gz Datei zu erstellen, die Mails vor dem Backup in den Ordner /home/users/xyz/mailbackup/ umkopieren.
Dann das Backup laufen lassen und nach dem Backup den Ordner /mailbackup wieder löschen.
Meines Erachtens nach müsste restic dann bei einer Sicherung im Backup bereits vorhandene E-Mails erkennen und nur noch die neuen E-Mails kopieren.

Tobi wrote: ↑Sun 4. Jun 2023, 18:59 Hallo Alex,

bitte korrigiere mich falls ich falsch liege.

Beim restic Backup werden die E-Mails zuerst in eine tar.gz Datei gepackt und dann übertragen.
Dies hängt mit der Rechtevergabe zusammen da der User keinen direkten Zugriff auf /var/mail/ hat.
Jedoch verhindert diese tar.gz Datei, dass restic effizient nur die Unterschiede abgleichen kann.
Es muss jedes Mal die gesamte Datei übertragen werden.
Ein Kunde mit 10 GB Mailspace belegt nach 10 Sicherungen 100 GB Backupspeicher.

Meine Idee:
Anstatt eine tar.gz Datei zu erstellen, die Mails vor dem Backup in den Ordner /home/users/xyz/mailbackup/ umkopieren.
Dann das Backup laufen lassen und nach dem Backup den Ordner /mailbackup wieder löschen.
Meines Erachtens nach müsste restic dann bei einer Sicherung im Backup bereits vorhandene E-Mails erkennen und nur noch die neuen E-Mails kopieren.

Dann müssten die Mails aber auch raw gespeichert werden im Backup.
Da Mails aber auch Anhänge enthalten können (die ggf. auch mal ver*** groß sein können) würde durch wegfall der tar.gz auch die Komprimierung wegfallen...

Tobi wrote: ↑Sun 4. Jun 2023, 18:59 Anstatt eine tar.gz Datei zu erstellen, die Mails vor dem Backup in den Ordner /home/users/xyz/mailbackup/ umkopieren.
Dann das Backup laufen lassen und nach dem Backup den Ordner /mailbackup wieder löschen.

Und wenn ein User 20 GB Mails im Postfach hat, und auf der Platte nur noch 10 GB frei sind?

OlliTheDarkness wrote: ↑Sun 4. Jun 2023, 20:09 Dann müssten die Mails aber auch raw gespeichert werden im Backup.
Da Mails aber auch Anhänge enthalten können (die ggf. auch mal ver*** groß sein können) würde durch wegfall der tar.gz auch die Komprimierung wegfallen...

https://forum.restic.net/t/compression- ... aster/4997

Das tgz an sich ist ein Problem, weil die Attachments dann eben nicht von der deduplicaion erkannt werden (können).

Restic does deduplication on blobs, per repository. A blob is usually only saved once in a repository.

https://forum.restic.net/t/how-does-res ... ate/2761/2

OlliTheDarkness wrote: ↑Sun 4. Jun 2023, 20:09 Dann müssten die Mails aber auch raw gespeichert werden im Backup.
Da Mails aber auch Anhänge enthalten können (die ggf. auch mal ver*** groß sein können) würde durch wegfall der tar.gz auch die Komprimierung wegfallen...

Korrekt.
Allerdings denke ich, dass die interne restic Komprimierung einen Teil ausgleichen wird, viel entscheidender ist jedoch aus meiner Sicht, dass die E-Mail mit dem 50 MB Anhang nur ein einziges Mal gesichert werden muss. Alle weiteren Backups verweisen dann auf die erste Sicherung.

Aktuell würde diese E-Mail, bei einer optimalen Kompression um den Faktor 10 schrumpfen, sprich nur 5 Megabyte belegen. Diese aber in jeder Sicherung aufs neue. Bei Backup Nr. 10 wären dann die Sicherungen bereits so groß wie das Original und ab dem elften Backup wird es ineffektiv.

Ich würde gerne ein 50 Backuppunkte (einen täglich) vorhalten. Der eine Kunde hat real 20 GB an E-Mails gesammelt. Im Backup belegen diese ca. 13 GB. Jeden Tag. Bereits der eine Kunde verursacht somit bereits einen Speicherbedarf von 650 GB. Und wie gesagt, das ist nur ein Kunde.
Wenn man das umstellen könnte würden am ersten Tag zwar 20 Gigabyte gespeichert, am zweiten Tag bereits nur noch die neu empfangenen E-Mails. Bei diesem Real-Beispiel ist der Break-Even Point bereits mit dem zweiten Backup erreicht...

24unix wrote: ↑Sun 4. Jun 2023, 20:20 Und wenn ein User 20 GB Mails im Postfach hat, und auf der Platte nur noch 10 GB frei sind?

Dann ist ein Backup nicht möglich mit der aktuellen Methode. Wie oben in meinem Real-Beispiel gezeigt, belegt aktuell ein 20 GB Backup ca. 13 GB Speicherplatz. Dieses tar.gz. muss ja irgendwo gespeichert werden

Fun fact:
Genau so ist mir das Problem auch erst aufgefallen, weil mir das Backup einfach die Platte vollgeballert hat bis zum einen die Webseiten mangels Cache alle hängengeblieben sind, MariaDB gestreikt hat und auch KeyHelp tot war. Ist ja klar...
Also vielleicht doch eher eine Fehlermeldung? Aber was kann KeyHelp dafür dass die Platte zu klein ist?

Grüße,

@Tobi,
Deine eingangs genannte Annahme ist soweit korrekt.

Ich habe noch ein zumindest theoretisch skizziertes Szenario für eine Umgestaltung der Art&Weise, wie das Restic Backup durchgeführt wird auf meiner Liste, habe es aber noch nie praktisch durchgespielt. Wenn das funktionieren sollte, dann sollten deine Probleme gelöst sein (Direkte Sicherung der Mails, ohne vorbereiten und umkopieren, keine "Backup-Vorbereitungszeit" mehr, außer für Datenbanken). Bis ich mich allerdings daran traue, kann durchaus noch etwas Zeit vergehen.


Hattest du das entsprechende Repo nach dem KeyHelp-Update vom 19. Januar 2023 neu angelegt? Erst dann greift die neue Restic-Komprimierung.

Alexander wrote: ↑Mon 5. Jun 2023, 10:18 Ich habe noch ein zumindest theoretisch skizziertes Szenario für eine Umgestaltung der Art&Weise, wie das Restic Backup durchgeführt wird auf meiner Liste, habe es aber noch nie praktisch durchgespielt.

Details magst du wohl nicht verraten?
Ich könnte mir noch vorstellen, dass man vielleicht die Ordnerrechte von /var/mail/vhosts/domain.tld auf "username:vmail" anpassen könnte. Dann sollte eine direkte Sicherung möglich sein. Ganz sicher bin ich mir aber wegen eventueller Nebenwirkungen bei den Ordnerrechten nicht.

Alexander wrote: ↑Mon 5. Jun 2023, 10:18
Bis ich mich allerdings daran traue, kann durchaus noch etwas Zeit vergehen.

So kompliziert?

Alexander wrote: ↑Mon 5. Jun 2023, 10:18
Hattest du das entsprechende Repo nach dem KeyHelp-Update vom 19. Januar 2023 neu angelegt? Erst dann greift die neue Restic-Komprimierung.

Ja.
Ich bin aktuell dabei alle Server auf restic umzustellen und hatte extra auf dieses Update gewartet.

Gerade mal auf dem Server live geguckt.
Bei einem E-Mail Account wurde doch überraschend wenig gesichert (1,6 GB), der andere steht unverändert bei 13 GB. Ich werde das jetzt noch beobachten und mich nochmal melden.

Vielleicht ist es doch nicht sooooooo schlimm wie eingangs gedacht...

Cool wäre z.b. ein rsync Backup Service z.b. bei Keyweb oder eine rsync Lösung wobei z.b. etwas über die API gebastelt werden müsste um user restores durchzuführen ... irgendein extra Modul für einen Backupserver, der quasi jeden Tag nur via rsync (ungepackt) die Daten erhält und erst auf dem Backupsystem packt (falls nötig) ein KH User müsste dann eine Art Key bekommen um eine Verbindung aufbauen zu können ....
Klingt vieleicht utopisch aber vom Resultat wäre es perfekt, kaum System Load auf dem KH System und es werden nur die veränderten Daten synced, der User müsste dann eben irgendwie über eine gesicherte Schnittstelle einen Restore auslösen können

Ralph wrote: ↑Fri 25. Aug 2023, 14:44 Cool wäre z.b. ein rsync Backup Service z.b. bei Keyweb oder eine rsync Lösung wobei z.b. etwas über die API gebastelt werden müsste um user restores durchzuführen ... irgendein extra Modul für einen Backupserver, der quasi jeden Tag nur via rsync (ungepackt) die Daten erhält und erst auf dem Backupsystem packt (falls nötig) ein KH User müsste dann eine Art Key bekommen um eine Verbindung aufbauen zu können ....
Klingt vieleicht utopisch aber vom Resultat wäre es perfekt, kaum System Load auf dem KH System und es werden nur die veränderten Daten synced, der User müsste dann eben irgendwie über eine gesicherte Schnittstelle einen Restore auslösen können

https://www.elkarbackup.org/

Tobi wrote: ↑Fri 25. Aug 2023, 17:47

Ralph wrote: ↑Fri 25. Aug 2023, 14:44 Cool wäre z.b. ein rsync Backup Service z.b. bei Keyweb oder eine rsync Lösung wobei z.b. etwas über die API gebastelt werden müsste um user restores durchzuführen ... irgendein extra Modul für einen Backupserver, der quasi jeden Tag nur via rsync (ungepackt) die Daten erhält und erst auf dem Backupsystem packt (falls nötig) ein KH User müsste dann eine Art Key bekommen um eine Verbindung aufbauen zu können ....
Klingt vieleicht utopisch aber vom Resultat wäre es perfekt, kaum System Load auf dem KH System und es werden nur die veränderten Daten synced, der User müsste dann eben irgendwie über eine gesicherte Schnittstelle einen Restore auslösen können

https://www.elkarbackup.org/

Sowas in der Art ... könnte man noch weiterspinnen z.b. als extra Key-Baclup-SSH Addon zur externen Anbindung.
Nach dem packen aus dem rsync Ordner in nur für die entsprechenden User zugänglichen Bereiche, könnte dann z.b. auch noch ein täglicher Malware-Check gestartet werden im offenen rsync Ordner - alles auf dem Backup System mit Admin Benachrichtigung ... Backup System sollte dann entsprechend viel Speicherplatz besitzen und Leistung, je nach eingestellter Anzahl von Tagen gepackter Backup Archive.
Kann man sich natürlich auch selber basteln, aber ich dachte hierbei an eine Art Extra Produkt -> Addon eben auf KH zugeschnitten, was dann eben zusätzlich für wenig Geld käuflich zu erwerben ist

Tobi wrote: ↑Fri 25. Aug 2023, 17:47 https://www.elkarbackup.org/

Das Projekt wird leider nicht mehr aktiv weiter entwickelt:

https://github.com/elkarbackup/elkarbackup/issues/657