Cloud-Backups sind über das VPN langsam: die echte Phase finden

Ein Backup, das über ein VPN kriecht, verleitet zum naheliegenden Experiment, den Tunnel zu trennen und erneut zu messen. Dieses Experiment beantwortet häufig eine andere Frage, denn der Job hat vielleicht Dateien gehasht oder auf einen Wiederholungsversuch gewartet, statt Bytes zu bewegen. Trennen Sie zuerst die Phasen, und die Beschwerde wird zu einem konkreten Test mit einem konkreten erwarteten Ergebnis. Die Route wird erst dann ein Kandidat, wenn tatsächlich die Übertragungsphase die langsame ist.

In welcher Phase steckt der Job, wenn er langsam wirkt

Backup-Werkzeuge durchlaufen Phasen: Dateien entdecken, sie lesen und hashen, komprimieren, verschlüsseln, hochladen und dann verifizieren. Jede Phase hat ihren eigenen Engpass, und nur einige berühren überhaupt das Netzwerk. Ein Werkzeug, das noch keine Phase meldet, sagt Ihnen, dass es das Scannen noch nicht abgeschlossen hat.

Ein Job, der zwanzig Minuten damit verbringt, eine Million kleiner Dateien vorzubereiten, wird nicht schneller, wenn der Tunnel schneller wird. Ein Job, der den Uplink sättigt, ist ein Kapazitätsproblem mit einer anderen Lösung. Lesen Sie die Fortschrittsausgabe, während die Verzögerung auftritt, notieren Sie die Phase und schreiben Sie den Zeitstempel auf, denn die Phase zum Zeitpunkt der Beschwerde ist die einzige, die zählt. Kleine Dateien verhalten sich auch anders als ein großes Objekt, weil Umläufe pro Datei dominieren und die Übertragung nie eine stabile Rate erreicht. Vergleichen Sie Gleiches mit Gleichem, bevor Sie Schlüsse über den Tunnel ziehen.

Ein öffentlicher Endpunkt und ein privates NAS scheitern unterschiedlich

Ein öffentlicher Backup-Dienst bringt seine eigene authentifizierte Anwendungsverbindung mit, und der Tunnel ist eine Station auf einem längeren Weg. Ein privates NAS hängt für die grundlegende Erreichbarkeit Ihres Netzwerks meist von diesem Tunnel ab. Dieser Unterschied entscheidet, ob das Trennen eine gültige Basislinie oder ein Test von nichts ist.

Im öffentlichen Fall kann derselbe Job über eine andere Route ein fairer Vergleich sein, wenn die Richtlinie es erlaubt. Im privaten Fall bleibt ohne den Tunnel überhaupt keine Route zum Server, sodass das Ergebnis den gelöschten Weg beschreibt und nicht den, den Sie nutzen.

Ein Stillstand ist ein anderer Fehler als eine langsame Übertragung

Die dritte Spalte dieser Tabelle entscheidet, ob ein Stabilitätstest überhaupt laufen kann, denn eine Basislinie, die den Tunnel entfernt, bedeutet nur dort etwas, wo ein anderer Weg existiert. Mit einer brauchbaren Basislinie betrachten Sie die Form des Fehlers statt seiner Durchschnittsrate. Ein niedriger, aber stetiger Upload deutet auf Kapazität, während ein Job, der stehen bleibt und neu startet, auf Unterbrechung, Authentifizierung oder eine einzelne störende Datei deutet. Diese beiden erzeugen fast identische Beschwerden und völlig unterschiedliche Reparaturen.

Wiederholungen verzerren jede Messung, denn die Bytes auf der Leitung können größer sein als die Menge, die sich tatsächlich geändert hat. Lesen Sie das Fortsetzungsverhalten, bevor Sie den Job erneut unterbrechen, um zu sehen, was passiert, denn unterteilte wiederaufnehmbare Uploads erholen sich günstig, Neustarts ganzer Dateien nicht. Ein Tunnel, der sich alle paar Minuten neu verbindet, sieht ebenfalls wie ein Bandbreitenproblem aus, wenn es in Wahrheit ein Stabilitätsproblem ist. Die Pfad-MTU verschärft das, denn ein Tunnel, der die nutzbare Nutzlast verringert, blockiert große Segmente, während kleine durchgehen.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

Ein Upload kann jeden anderen Fluss aushungern

Ein Upload, der die Uplink-Leitung füllt, macht Anrufe und Surfen unempfindlich, und das Backup ist selten das Einzige, was darum konkurriert. Ein zweiter Sync-Client erzeugt dasselbe Symptom von allein. Bevor Sie den Tunnel beschuldigen, schauen Sie, was sonst noch hochlädt.

Verwenden Sie den Zeitplan oder die Bandbreitengrenze, die das Werkzeug dokumentiert, statt um Spitzendurchsatz zu kämpfen; für interaktive Arbeit Platz zu lassen ist meist mehr wert als die letzten Prozent. Prüfen Sie dann, worauf die Grenze tatsächlich wirkt, denn manche Werkzeuge begrenzen pro Datei, andere den gesamten Lauf, und manche ignorieren den Overhead kleiner Dateien völlig. Eine Grenze, die nicht zur Arbeitslast passt, ändert nichts. Auch Split-Tunneling verdient hier Misstrauen, denn den Launcher vom Tunnel auszunehmen nimmt nicht den Hilfsdienst aus, der den Upload ausführt. Rclone etwa veröffentlicht sowohl Übertragungsgrenzen als auch Wiederholungsverhalten in seiner Dokumentation, was es zu einer nützlichen Referenz dafür macht, was eine Grenze steuern sollte.

Schließen Sie mit einer Wiederherstellung ab, nicht mit einem Geschwindigkeitstest

Ein abgeschlossener Upload ist kein Backup, bis etwas daraus wiederhergestellt wird. Bestätigen Sie, dass die erwartete Version existiert, und stellen Sie dann eine repräsentative Datei mit dem dokumentierten Verfahren wieder her. Bewahren Sie die Wiederherstellungsinformationen an einem anderen Ort auf als auf dem Rechner oder Profil, das Sie verlieren könnten, und werfen Sie niemals ein funktionierendes Backup weg, nur um ein Experiment ordentlich zu halten.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

Wiederholen Sie sowohl die Übertragung als auch die Wiederherstellung nach der Netzwerkänderung, damit die Verbesserung dem Backup dient und nicht bloß Daten schneller bewegt. Der zweite Lauf ist es, der das Ticket schließt. Eine schnellere Übertragung mit ungetesteter Wiederherstellung ist ein langsamerer Weg, ungeschützt zu bleiben.