Cloudbackups er langsomme over VPN: find den rigtige fase

En backup, der kravler over en VPN, indbyder til det oplagte eksperiment at afbryde tunnelen og måle igen. Det eksperiment besvarer ofte et andet spørgsmål, fordi jobbet måske har hashet filer eller ventet på et genforsøg i stedet for at flytte bytes. Adskil først faserne, og klagen bliver til en konkret test med et konkret forventet resultat. Ruten bliver først en kandidat, når det er overførselsfasen, der faktisk er langsom.

Hvilken fase er jobbet i, når det føles langsomt

Backupværktøjer gennemløber faser: finde filer, læse og hashe dem, komprimere, kryptere, uploade og derefter verificere. Hver fase har sin egen flaskehals, og kun nogle af dem rører netværket overhovedet. Et værktøj, der endnu ikke rapporterer nogen fase, fortæller dig, at det ikke er færdigt med at skanne.

Et job, der bruger tyve minutter på at forberede en million små filer, bliver ikke hurtigere, når tunnelen bliver hurtigere. Et job, der mætter uplinket, er et kapacitetsproblem med en anden løsning. Læs statusoutputtet, mens forsinkelsen varer, noter fasen, og skriv tidsstemplet ned, fordi fasen på klagetidspunktet er den eneste, der betyder noget. Små filer opfører sig også anderledes end ét stort objekt, fordi rundture pr. fil dominerer, og overførslen når aldrig en stabil hastighed. Sammenlign ens med ens, før du drager konklusioner om tunnelen.

Et offentligt endepunkt og en privat NAS fejler forskelligt

En offentlig backuptjeneste har sin egen autentificerede applikationsforbindelse, og tunnelen er et hop på en længere vej. En privat NAS afhænger normalt af den tunnel for grundlæggende adgang til dit netværk. Den forskel afgør, om afbrydelsen er en gyldig baseline eller en test af ingenting.

I det offentlige tilfælde kan det samme job over en anden rute være en fair sammenligning, når politikken tillader det. I det private tilfælde efterlader fjernelsen af tunnelen slet ingen rute til serveren, så resultatet beskriver den vej, du slettede, i stedet for den, du bruger.

Et stop er en anden fejl end en langsom overførsel

Den tredje kolonne i tabellen afgør, om en stabilitetstest overhovedet kan køre, fordi en baseline, der fjerner tunnelen, kun betyder noget, hvor der findes en anden vej. Med en brugbar baseline skal du se på fejlens form i stedet for dens gennemsnitlige hastighed. En lav men stabil upload peger på kapacitet, mens et job, der stopper og genstarter, peger på afbrydelse, autentificering eller én besværlig fil. De to giver næsten identiske klager og helt forskellige reparationer.

Genforsøg forvrænger enhver måling, fordi bytes på nettet kan være større end den mængde, der faktisk ændrede sig. Læs genoptagelsesadfærden, før du afbryder jobbet igen for at se, hvad der sker, fordi opdelte genoptagelige uploads kommer sig billigt, og genstart af hele filer gør ikke. En tunnel, der genopretter forbindelse hvert par minutter, ligner også et båndbreddeproblem, når det i virkeligheden er et stabilitetsproblem. Stiens MTU forværrer det, fordi en tunnel, der reducerer den brugbare nyttelast, stopper store segmenter, mens små passerer.

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

En upload kan udsulte alle andre flows

En upload, der fylder uplinket, gør opkald og browsing uresponsive, og backuppen er sjældent det eneste, der konkurrerer om det. En ekstra synkroniseringsklient giver samme symptom af sig selv. Før du bebrejder tunnelen, se på hvad der ellers uploader.

Brug den tidsplan eller båndbreddegrænse, som værktøjet dokumenterer, i stedet for at kæmpe for spidsgennemstrømning; at efterlade plads til interaktivt arbejde er normalt mere værd end de sidste par procent. Kontroller derefter, hvad grænsen faktisk gælder for, fordi nogle værktøjer begrænser pr. fil, nogle begrænser hele kørslen, og nogle ignorerer overhead for små filer helt. En grænse, der ikke passer til arbejdsbyrden, ændrer intet. Split tunneling fortjener også mistanke her, fordi at udelukke launcheren fra tunnelen ikke udelukker den hjælpetjeneste, der udfører uploadet. Rclone offentliggør for eksempel både overførselsgrænser og genforsøgsadfærd i sin dokumentation, hvilket gør det til en nyttig reference for, hvad en grænse bør styre.

Slut med en gendannelse, ikke en hastighedstest

En gennemført upload er ikke en backup, før noget gendannes fra det. Bekræft, at den forventede version findes, og gendan derefter en repræsentativ fil med den procedure, værktøjet dokumenterer. Opbevar gendannelsesoplysningerne et andet sted end den maskine eller profil, du kan miste, og smid aldrig en backup væk, der virker, bare for at holde et eksperiment pænt.

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

Gentag både overførslen og gendannelsen efter netværksændringen, så forbedringen viser sig at tjene backuppen og ikke blot at flytte data hurtigere. Det er den anden kørsel, der lukker sagen. En hurtigere overførsel med en utestet gendannelse er en langsommere måde at forblive ubeskyttet.