Molnbackuper är långsamma över VPN: hitta den verkliga fasen
En långsam backup kan skanna, hasha eller försöka igen i stället för att överföra. Jämför fasen, målets typ och återställningen innan du ändrar rutter.
En backup som kryper fram över ett VPN inbjuder till det uppenbara experimentet att koppla ned tunneln och mäta igen. Det experimentet svarar ofta på en annan fråga, eftersom jobbet kanske hashade filer eller väntade på ett nytt försök i stället för att flytta byte. Dela först upp faserna, och klagomålet blir ett konkret test med ett konkret förväntat resultat. Rutten blir först en kandidat när det är överföringsfasen som faktiskt är långsam.
I vilken fas är jobbet när det känns långsamt
Backupverktyg går igenom faser: upptäcka filer, läsa och hasha dem, komprimera, kryptera, ladda upp och sedan verifiera. Varje fas har sin egen flaskhals, och bara några av dem rör nätverket alls. Ett verktyg som ännu inte rapporterar någon fas säger att det inte har skannat klart.
Ett jobb som lägger tjugo minuter på att förbereda en miljon små filer blir inte snabbare när tunneln blir snabbare. Ett jobb som mättar upplänken är ett kapacitetsproblem med en annan lösning. Läs förloppsutskriften medan fördröjningen pågår, anteckna fasen och skriv ner tidsstämpeln, för fasen vid klagomålet är den enda som spelar roll. Små filer beter sig också annorlunda än ett stort objekt, eftersom tur och retur per fil dominerar och överföringen aldrig når en stabil hastighet. Jämför lika med lika innan du drar slutsatser om tunneln.
En publik slutpunkt och en privat NAS misslyckas olika
En publik backuptjänst har sin egen autentiserade applikationsanslutning, och tunneln är ett hopp på en längre väg. En privat NAS är vanligtvis beroende av den tunneln för grundläggande nåbarhet till ditt nätverk. Den skillnaden avgör om frånkoppling är en giltig baslinje eller ett test av ingenting.
I det publika fallet kan samma jobb över en annan rutt vara en rättvis jämförelse när policyn tillåter det. I det privata fallet lämnar borttagningen av tunneln ingen rutt till servern alls, så resultatet beskriver vägen du raderade och inte den du använder.
| Destination | What the tunnel provides | Valid baseline |
|---|---|---|
| Public backup service | One hop among several | The same job over another route |
| Private NAS | The only path to the server | None that removes the tunnel |
| Self-hosted gateway | Path plus split-DNS policy | Only if the policy is unchanged |
Ett stopp är ett annat fel än en långsam överföring
Den tredje kolumnen i tabellen avgör om ett stabilitetstest alls kan köras, eftersom en baslinje som tar bort tunneln bara betyder något där det finns en annan väg. Med en användbar baslinje tittar du på felets form i stället för dess medelhastighet. En låg men jämn uppladdning pekar på kapacitet, medan ett jobb som stannar och startar om pekar på avbrott, autentisering eller en besvärlig fil. De två ger nästan identiska klagomål och helt olika reparationer.
Nya försök förvränger varje mätning, eftersom byten på ledningen kan vara fler än mängden som faktiskt ändrades. Läs återupptagningsbeteendet innan du avbryter jobbet igen för att se vad som händer, eftersom delade återupptagbara uppladdningar återhämtar sig billigt och omstarter av hela filen inte. En tunnel som återansluter var par minut ser också ut som ett bandbreddsproblem när det egentligen är ett stabilitetsproblem. Stigens MTU förvärrar detta, eftersom en tunnel som minskar nyttolasten stoppar stora segment medan små passerar.
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com
En uppladdning kan svälta alla andra flöden
En uppladdning som fyller upplänken gör samtal och surf oresponsiva, och backuppen är sällan det enda som konkurrerar om den. En andra synkklient ger samma symptom på egen hand. Innan du skyller på tunneln, titta på vad annat som laddar upp.
Använd schemat eller bandbreddsgränsen som verktyget dokumenterar i stället för att kämpa för toppgenomströmning; att lämna utrymme för interaktivt arbete är oftast värt mer än de sista procenten. Kontrollera sedan vad gränsen faktiskt gäller, eftersom vissa verktyg begränsar per fil, andra hela körningen och andra ignorerar overhead för små filer helt. En gräns som inte passar arbetsbelastningen ändrar ingenting. Delad tunneling förtjänar också misstanke här, eftersom att utesluta startprogrammet från tunneln inte utesluter hjälptjänsten som utför uppladdningen. Rclone publicerar till exempel både överföringsgränser och återförsöksbeteende i sin dokumentation, vilket gör det till en användbar referens för vad en gräns bör styra.
Avsluta med en återställning, inte ett hastighetstest
En slutförd uppladdning är inte en backup förrän något återställs från den. Bekräfta att den förväntade versionen finns och återställ sedan en representativ fil med proceduren som verktyget dokumenterar. Förvara återställningsinformationen någon annanstans än på maskinen eller profilen du kan förlora, och släng aldrig en fungerande backup bara för att hålla ett experiment snyggt.
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts
Upprepa både överföringen och återställningen efter nätverksändringen, så att förbättringen visas tjäna backuppen och inte bara flytta data snabbare. Det är den andra körningen som stänger ärendet. En snabbare överföring med en otestad återställning är ett långsammare sätt att förbli oskyddad.