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

  • Hallo miteinander,


    ich verwende BorgBackup nun schon seit einigen Jahren für meine lokalen Rechner, jetzt würde ich damit auch gerne die Daten des vServers bei mir lokal sichern. Es handelt sich um einen VPS 1000 G8.

    Das Problem: Das Kopieren vieler kleiner Dateien führt latenz- und overheadbedingt zu einer durchschnittlichen Übertragungsrate von unter 100 kB/s. Große Dateien nutzen die Bandbreite (sind auch nur 5MB/s) hingegen aus.


    Das ist kein Problem mit BorgBackup per se. Ich habe zwar sowohl sshfs als auch nfs/openvpn zum Einbinden des Root-Verzeichnisses des vServers ausprobiert, und das Ergebnis schenkt sich nix.

    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.


    Ich habe schon einmal ein vollständiges Backup gemacht (mit sshfs) und so um die 4-5h gebraucht für gerade mal 5GB Daten. Und das kann halt echt nicht die Lösung sein. Ich weiß, dass das erste Backup länger dauert, aber 5GB ist nun wirklich keine Hausnummer wenn von Heute auf Morgen mal 30GB dazukommen können.


    Verhält es sich bei Euch ähnlich, oder kann man dies sinnvoll optimieren?


    Noch kurz zum Setup, auf Client und Server laufen ein aktuelles Arch Linux, entsprechend liegt eigentlich alles in der aktuellsten Version vor. Der Server ist im Idle-Zustand und ich verwende ufw mit für Input freigegebenen Ports 80, 443, 111, 2049, 20048 (nfs), 1194/udp (vpn).


    Edit: Vielleicht mache ich es auch genau verkehrt rum, und ich sollte auf dem vServer einen Borg-Client starten und bei mir lokal den Server?

    Ich könnte mir vorstellen dass borg dann Chunks bilden kann, welche mit weniger TCP-Overhead übertragen werden...

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

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

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

  • So, da bin ich wieder. Ich glaube ich habe es hinbekommen \o/

    Zunächst einmal ein ganz großes Dankeschön an alle für die hilfreichen Beiträge!


    Ich habe das jetzt via BorgBackup gelöst, im Wesentlichen wie Andi22 vorgeschlagen hat. Die Voraussetzungen über den bestehenden VPN-Tunnel waren ja teilweise schon da und in eine zweite Backup-Lösung wollte ich mich aus Komplexitätsgründen jetzt nicht auch noch einarbeiten.

    So hat das initiale Backup in ein neues Repository in 20min funktioniert :)