Backup-Strategie bei hoher Latenz und vielen kleinen Dateien? Mit Borg-Backup machbar?

Quote from mbw

Aber auch ein einfaches "scp -r <remote host>:/usr/share/man ." (viele kleine Dateien) drückt die Übertragungsrate reproduzierbar auf ca. 40 kB/s runter.

Das ist sicherlich der schlechteste Fall/Ansatz, da scp nicht inkrementell arbeitet. Sowohl Borg-Backup (welches ich nicht nutze) als auch rsync via ssh (welches ich al­ler­dings ausschließlich für größere Archiv-Dateien und Netcup-RS nutze) sollten hier besser abschneiden.

Eine weitere Möglichkeit, wenn Änderungen schon allein am letzten Modifikationszeitpunkt festgemacht werden können (vgl. find -mtime), wäre, nur die betref­fen­den Da­tei­en zuerst lokal zu archivieren und dann dieses Archiv via scp zu übertragen (unter der Voraussetzung, dass verschachtelte Lese-/Schreib­ope­ra­tio­nen in Sum­me mit der Übertragung von einer/wenigen "maximalgroßen" Archivdatei(en) schnel­ler sind, weil hier ggf. ein Caching ausgenutzt werden kann).

Bei Platzmangel hat tar die Möglichkeit, das zu erstellende Archiv in Teile zu schneiden, welche beliebig groß sein können (vgl. tar --multi-volume --files-from=$(find ...)) und diese Teile können während ih­rer Erstellung auf /tmp (=RAM-Disk!) liegen, bevor sie (ggf. einzeln kom­pri­miert und ggf. auch nochmals verschlüsselt; das geschieht über ein Script, welches man tar via --new-volume-script übergeben kann) in einem Zielverzeichnis lan­den, welches ggf. direkt via sshfs/GlusterFS o. Ä. "auf den heimischen Rechner verweist". Damit entsteht im Rahmen der Archivierung keinerlei Da­tei­system-Over­head auf dem VPS (=temporär belegter Platz auf der virtuellen Platte) und die resultierenden Teilarchive sollten mit maximaler Geschwindigkeit über­tra­gen werden können. Ich selbst nutze diesen Ansatz in abgewandelter Form zusammen mit rclone statt sshfs, um Archive in der Cloud abzulegen und jedes Teil­archiv (über das vorgenannte Script) zudem via par2 vor Bitrot zu schützen.

(Der Vollständigkeit halber: Bei rclone gibt es i.d.R. einen lokalen Dateisystem-Overhead, da man hier einen Festplatten-Cache verwendet; diesen kann man allerdings begrenzen.)

Hallo mbw,

Du musst BorgBackup auf Deinem VPS installieren und von dort aus in ein Remote Repository sichern.

Das Remote Repository liegt dann bei Dir lokal, und muss von Deinem VPS aus mittels SSH angesprochen werden können.

Da Du zu Hause wahrscheinlich keine statische IP hast, würde ich den lokalen SSH-Server über Deine vorhandene openvpn Verbindung ansprechen.

Eine andere Option wäre DynDNS, aber dann müsstest Du auf Deinem Router einen Port für SSH öffnen, was selbst mit einem geänderten Port (nicht 22) sicher eine schlechtere Lösung ist, als das vorhandene VPN zu verwenden.

Dann sollte auch die Geschwindigkeit passen, da borg dann nur noch wenige große Dateien überträgt, die dann ja auch komprimiert und dedupliziert sind.

Wenn Du auf dem VPS genügend Platz frei hast, kannst Du natürlich auch ein lokales Repostiory verwenden, und das dann täglich per rsync auf Deinen lokalen Rechner kopieren. Das geht dann auch schnell.

Hi,

ich verwende für tägliche Backups einen Server bei mir zuhause auf welchem ein Minio S3-Server läuft, dieser ist dank Frp (https://github.com/fatedier/frp) von außen erreichbar (ohne VPN, Port Freischaltung o.ä.) und auf dem Server selbst läuft jede Nacht Restic (https://restic.net/) mit dem S3 Bucket als Backup Destination. Das funktioniert für meine Belange ziemlich gut. Und auch Restic verwendet inktementelle Backups ist also entsprechend schnell.

Ja, restic verwende ich auf meinen Servern mit Keyhelp ebenfalls. Das ist recht flott, allerdings werden die Daten per SFTP auf einen anderen Netcup-Server oder auch Webhostings bei Netcup und anderswo übertragen. Ich habe auch nicht nur kleine Dateien, sondern es sind auch Bilder dabei, die vom benötigten Plattenplatz her - aber nicht von der Zahl der Dateien her, da sind die kleinen Dateien viel zahlreicher- sicher den Großteil der Daten ausmachen. Die ca 6 GB beim ersten Backup waren in weniger als einer halben Stunde durch, jetzt dauert es höchstens noch 10 Minuten. Ich tausche aber auch nicht pro Tag 30 GB Daten aus. Und schon gar nicht 30 GB in kleinen Dateien.