restic und das E-Mail Backup

[Tobi]

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.

[OlliTheDarkness]

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...

[24unix]

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?

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

[Tobi]

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...

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?

[Alexander]

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.

[Tobi]

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.

Bis ich mich allerdings daran traue, kann durchaus noch etwas Zeit vergehen.

So kompliziert?

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...

[Ralph]

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

[Tobi]

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/

[Ralph]

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

[l_fish]

https://www.elkarbackup.org/

Das Projekt wird leider nicht mehr aktiv weiter entwickelt:

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

[Krisi]

Auch wenn ich dieses Thema immer im Hinterkopf hatte, so ist es gerade wieder aktuell geworden.
Wegen eines Hardwaredefekts fehlen Daten von 4 Tagen. Aus dem Grund überlege ich, in Zukunft ein tägliches externes Backup einzurichten.

Ich habe einen User mit 100 GB Mails (es ist davon auszugehen, dass das in Zukunft noch deutlich mehr wird). Ein tägliches Backup mit restic durchzuführen ist möglich, verursacht aber doch recht lange Zeit sehr hohe Last beim Vorbereiten.
Das Vorhalten von so viel Speicherplatz ist auch alles andere als optimal.
Außerdem ist der Traffic von 3 TB im Monat allein durch das Backup nicht ganz wenig.

Spricht etwas dagegen, einen cron job als root mit rsync Befehl einzurichten und das per SSH zu übertragen?
Ziel wäre ein /home/user/files/manual_backup/ Verzeichnis auf einer anderen Maschine.

@Alexander
Deine neuere Methode wäre ein ganz großer Schritt nach vorne.
Es würde dann lediglich der Traffic anfallen. Das reine Lesen der Daten bei der Datenübertragung belastet moderne SSDs ja kaum mehr.
Es würde nicht nur das Platzproblem beseitigt, sondern auch das entstehende Lastproblem (man kann es in die Nacht legen, klar).
Das wären 2 Fliegen mit einer Klatsche.

Links

• https://www.marksanborn.net/howto/use-r ... y-backups/

• http://www.mikerubel.org/computers/rsync_snapshots/

• https://rdiff-backup.net/

• https://rsnapshot.org/

[Virinum]

Also ich habe das Problem so gelöst, dass ich ein Backup als Admin-User eingerichtet und folgende Einstellungen gewählt habe:

Bildschirmfoto 2024-05-29 um 09.20.06.png (40.1 KiB) Viewed 3406 times

Oder spricht da aus eurer Sicht irgendwas gegen?

[Ralph]

Habe hier leider auch ein System wo die Backups (extern) via rsync gesichert werden müssen, die KH Backups musste ich auf diesem System deaktivieren aufgrund der großen User Accounts -> zu lange Laufzeit und Last.

@Alexander
Dazu habe ich auch noch eine Frage, sind ab Keyhelp 23.2 neue Backup Pfade hinzugekommen bzw. sind hier alle notwendigen Pfade enthalten?

Code: Select all

/home --exclude=/home/users/*/logs --exclude=/home/users/*/tmp
/etc
/root
/var/mail/vhosts
/var/cache/bind
/var/spool/cron
/var/lib/rspamd
/opt

[Krisi]

Habe hier leider auch ein System wo die Backups (extern) via rsync gesichert werden müssen, die KH Backups musste ich auf diesem System deaktivieren aufgrund der großen User Accounts -> zu lange Laufzeit und Last.

Kannst du mir Tipps zur Einrichtung geben?

@Virinum
Auf wen war dein Beitrag bezogen?

[Ralph]

Kannst du mir Tipps zur Einrichtung geben?

Beispiel:
SSH Key fürs Backup System erstellen und zur (quelle /root) via scp irgendwo sichern (im Beispiel /root/mykey/backup-key)
Bash Script erstellen (ausführbar) am besten auch unter Quelle /root

Code: Select all

# testen ob ssh verbindung möglich ist
if [ -n "$(ssh -p 22 -i /root/mykey/backup-key "root@xxx.xxx.xxx.xxx" [ -d "/backup" ] && echo 1; exit)" ]; then

# hier alle Pfade anlegen und ggf. exclusions
ionice -c 3 rsync -avze "ssh -p 22 -i /root/mykey/backup-key" --stats  --numeric-ids  --delete /home --exclude=/home/users/*/logs --exclude=/home/users/*/tmp root@xxx.xxx.xxx.xxx:/backup/hostname

# usw.

# eventl. extra mysql dumps (KH database und/oder kompletter dump
# mysqldump --opt --system=all --insert-ignore --allow-keywords --flush-logs --hex-blob --quote-names --all-databases > /backup/fulldump.sql
# scp -P 22 -i /root/mykey/backup-key /backup/fulldump.sql root@xxx.xxx.xxx.xxx:/backup/hostname/fulldump.sql

else
    echo "Rsync Backup Connect Error" | mail -s "Rsync Backup Connect Error" myadmin@email.tld
fi

Cron Jobs:
Verwende am besten 2 versetzte Backup Tasks jeweils jeden 2. Tag, somit kannst du max. 48 Stunden bzw. je nach Intervall auf diese zugreifen.
Also z.b. 2 Backup Scripts mit verschiedenen Pfaden auf dem Backup System, z.b. backup1.sh und backup2.sh die dann mit 2 Cronjobs jeden 2. Tag ausgeführt werden ...