Cloudback-ups zijn traag via de VPN: vind de echte fase

Een back-up die via een VPN voortkruipt, nodigt uit tot het voor de hand liggende experiment: de tunnel loskoppelen en opnieuw meten. Dat experiment beantwoordt vaak een andere vraag, want de taak was misschien bestanden aan het hashen of op een herhaling aan het wachten in plaats van bytes te verplaatsen. Splits eerst de fasen en de klacht wordt een concrete test met een concreet verwacht resultaat. De route wordt pas een kandidaat als de overdrachtsfase de fase is die echt traag is.

In welke fase zit de taak als het traag voelt

Back-uptools doorlopen fasen: bestanden ontdekken, ze lezen en hashen, comprimeren, versleutelen, uploaden en daarna verifiëren. Elke fase heeft zijn eigen knelpunt, en slechts enkele raken überhaupt het netwerk. Een tool die nog geen fase meldt, vertelt u dat het nog niet klaar is met scannen.

Een taak die twintig minuten besteedt aan het voorbereiden van een miljoen kleine bestanden, wordt niet sneller als de tunnel sneller wordt. Een taak die de uploadlink verzadigt, is een capaciteitsprobleem met een andere oplossing. Lees de voortgangsuitvoer terwijl de vertraging optreedt, noteer de fase en schrijf de tijdstempel op, want de fase op het moment van de klacht is de enige die ertoe doet. Kleine bestanden gedragen zich ook anders dan één groot object, omdat rondreizen per bestand domineren en de overdracht nooit een stabiel tempo bereikt. Vergelijk gelijke gevallen voordat u conclusies over de tunnel trekt.

Een publiek eindpunt en een privé-NAS falen anders

Een openbare back-updienst heeft zijn eigen geauthenticeerde applicatieverbinding, en de tunnel is één hop op een langer pad. Een privé-NAS is meestal afhankelijk van die tunnel voor basisbereikbaarheid van uw netwerk. Dat verschil bepaalt of loskoppelen een geldige basislijn is of een test van niets.

In het openbare geval kan dezelfde taak via een andere route een eerlijke vergelijking zijn als het beleid dat toestaat. In het privégeval laat het verwijderen van de tunnel helemaal geen route naar de server over, dus het resultaat beschrijft het pad dat u hebt verwijderd en niet het pad dat u gebruikt.

Een stilstand is een ander falen dan een trage overdracht

De derde kolom van die tabel bepaalt of een stabiliteitstest überhaupt kan lopen, omdat een basislijn die de tunnel verwijdert alleen iets betekent waar een ander pad bestaat. Met een bruikbare basislijn kijkt u naar de vorm van het falen in plaats van de gemiddelde snelheid. Een lage maar gestage upload wijst op capaciteit, terwijl een taak die vastloopt en opnieuw start wijst op onderbreking, authenticatie of één lastig bestand. Die twee veroorzaken bijna identieke klachten en volledig verschillende reparaties.

Herhalingen vertekenen elke meting, omdat de bytes op de lijn groter kunnen zijn dan de hoeveelheid die werkelijk is veranderd. Lees het hervatgedrag voordat u de taak opnieuw onderbreekt om te zien wat er gebeurt, want gesplitste hervatbare uploads herstellen goedkoop en herstarts van hele bestanden niet. Een tunnel die elke paar minuten opnieuw verbindt, ziet er ook uit als een bandbreedteprobleem terwijl het in werkelijkheid een stabiliteitsprobleem is. De pad-MTU verergert dit, want een tunnel die de bruikbare payload verkleint, laat grote segmenten vastlopen terwijl kleine passeren.

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

Eén upload kan alle andere stromen uithongeren

Een upload die de uploadlink vult, maakt gesprekken en browsen onresponsief, en de back-up is zelden het enige dat erom concurreert. Een tweede synchronisatieclient veroorzaakt hetzelfde symptoom vanzelf. Voordat u de tunnel de schuld geeft, kijk wat er nog meer uploadt.

Gebruik de planning of bandbreedtelimiet die de tool documenteert in plaats van te vechten voor piekdoorvoer; ruimte overlaten voor interactief werk is meestal meer waard dan de laatste procenten. Controleer dan waarop de limiet echt van toepassing is, want sommige tools beperken per bestand, andere de hele run, en weer andere negeren de overhead van kleine bestanden volledig. Een limiet die niet bij de werklast past, verandert niets. Ook split-tunneling verdient hier argwaan, want de launcher van de tunnel uitsluiten sluit de hulpdienst die de upload uitvoert niet uit. Rclone publiceert bijvoorbeeld zowel overdrachtslimieten als herhaalgedrag in zijn documentatie, wat het een nuttige referentie maakt voor wat een limiet zou moeten beheersen.

Sluit af met een herstel, niet met een snelheidstest

Een voltooide upload is geen back-up tot er iets uit wordt hersteld. Bevestig dat de verwachte versie bestaat en herstel dan een representatief bestand met de procedure die de tool documenteert. Bewaar de herstelinformatie ergens anders dan op de machine of het profiel dat u kunt verliezen, en gooi nooit een werkende back-up weg alleen om een experiment netjes te houden.

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

Herhaal zowel de overdracht als het herstel na de netwerkwijziging, zodat de verbetering aantoonbaar de back-up dient en niet alleen gegevens sneller verplaatst. Die tweede run is wat het ticket sluit. Een snellere overdracht met een ongetest herstel is een langzamere manier om onbeschermd te blijven.