Skysikkerhetskopier er trege over VPN: finn den virkelige fasen

En sikkerhetskopi som kryper over en VPN inviterer til det åpenbare eksperimentet å koble fra tunnelen og måle på nytt. Det eksperimentet svarer ofte på et annet spørsmål, fordi jobben kanskje har hashet filer eller ventet på et nytt forsøk i stedet for å flytte bytes. Skill fasene først, og klagen blir en konkret test med et konkret forventet resultat. Ruten blir først en kandidat når det er overføringsfasen som faktisk er treg.

Hvilken fase er jobben i når den føles treg

Sikkerhetskopiverktøy går gjennom faser: oppdage filer, lese og hashe dem, komprimere, kryptere, laste opp og deretter verifisere. Hver fase har sin egen flaskehals, og bare noen av dem berører nettverket i det hele tatt. Et verktøy som ennå ikke rapporterer noen fase, forteller deg at det ikke er ferdig med skanningen.

En jobb som bruker tjue minutter på å forberede en million små filer, blir ikke raskere når tunnelen blir raskere. En jobb som metter oppstrømslenken, er et kapasitetsproblem med en annen løsning. Les fremdriftsutskriften mens forsinkelsen pågår, noter fasen og skriv ned tidsstemplet, fordi fasen på klagetidspunktet er den eneste som betyr noe. Små filer oppfører seg også annerledes enn ett stort objekt, fordi rundturer per fil dominerer og overføringen aldri når en stabil hastighet. Sammenlign likt med likt før du trekker konklusjoner om tunnelen.

Et offentlig endepunkt og en privat NAS feiler ulikt

En offentlig sikkerhetskopitjeneste har sin egen autentiserte applikasjonstilkobling, og tunnelen er ett hopp på en lengre vei. En privat NAS avhenger vanligvis av den tunnelen for grunnleggende tilgjengelighet til nettverket ditt. Den forskjellen avgjør om frakobling er en gyldig basislinje eller en test av ingenting.

I det offentlige tilfellet kan den samme jobben over en annen rute være en rettferdig sammenligning når policyen tillater det. I det private tilfellet etterlater fjerning av tunnelen ingen rute til serveren i det hele tatt, så resultatet beskriver veien du slettet og ikke den du bruker.

En stopp er en annen feil enn en treg overføring

Den tredje kolonnen i den tabellen avgjør om en stabilitetstest i det hele tatt kan kjøres, fordi en basislinje som fjerner tunnelen bare betyr noe der det finnes en annen vei. Med en brukbar basislinje ser du på feilens form i stedet for gjennomsnittshastigheten. En lav men jevn opplasting peker på kapasitet, mens en jobb som stopper og starter på nytt peker på avbrudd, autentisering eller én plagsom fil. De to gir nesten identiske klager og helt forskjellige reparasjoner.

Nye forsøk forvrenger enhver måling, fordi bytene på linjen kan være større enn mengden som faktisk endret seg. Les gjenopptakelsesatferden før du avbryter jobben igjen for å se hva som skjer, fordi oppdelte gjenopptakbare opplastinger kommer seg billig og omstart av hele filen ikke. En tunnel som kobler til på nytt hvert par minutter, ser også ut som et båndbreddeproblem når det egentlig er et stabilitetsproblem. Stiens MTU forsterker dette, fordi en tunnel som reduserer nyttelasten stopper store segmenter mens små slipper gjennom.

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

Én opplasting kan sulte alle andre strømmer

En opplasting som fyller oppstrømslenken, gjør anrop og nettlesing uresponsive, og sikkerhetskopien er sjelden det eneste som konkurrerer om den. En ekstra synkroniseringsklient gir samme symptom på egen hånd. Før du klandrer tunnelen, se på hva annet som laster opp.

Bruk tidsplanen eller båndbreddegrensen verktøyet dokumenterer i stedet for å kjempe for topp gjennomstrømning; å la det være plass til interaktivt arbeid er vanligvis verdt mer enn de siste prosentene. Sjekk deretter hva grensen faktisk gjelder, fordi noen verktøy begrenser per fil, noen begrenser hele kjøringen og noen ignorerer overhead for små filer helt. En grense som ikke passer arbeidsmengden, endrer ingenting. Splitt-tunneling fortjener også mistanke her, fordi å utelukke launcheren fra tunnelen ikke utelukker hjelpetjenesten som utfører opplastingen. Rclone publiserer for eksempel både overføringsgrenser og gjenforsøksatferd i dokumentasjonen sin, noe som gjør det til en nyttig referanse for hva en grense bør styre.

Avslutt med en gjenoppretting, ikke en hastighetstest

En fullført opplasting er ikke en sikkerhetskopi før noe gjenopprettes fra den. Bekreft at den forventede versjonen finnes, og gjenopprett deretter en representativ fil med prosedyren verktøyet dokumenterer. Oppbevar gjenopprettingsinformasjonen et annet sted enn maskinen eller profilen du kan miste, og kast aldri en sikkerhetskopi som virker bare for å holde et eksperiment ryddig.

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

Gjenta både overføringen og gjenopprettingen etter nettverksendringen, slik at forbedringen viser seg å tjene sikkerhetskopien og ikke bare å flytte data raskere. Det er den andre kjøringen som lukker saken. En raskere overføring med en utestet gjenoppretting er en tregere måte å forbli ubeskyttet.