I backup sul cloud sono lenti via VPN: trova la fase reale

Un backup che si trascina attraverso una VPN invita all'esperimento ovvio: scollegare il tunnel e misurare di nuovo. Quell'esperimento spesso risponde a un'altra domanda, perché il lavoro potrebbe aver calcolato hash dei file o atteso un nuovo tentativo invece di spostare byte. Separa prima le fasi e la lamentela diventa un test preciso con un risultato atteso preciso. La route diventa candidata solo quando è la fase di trasferimento a essere davvero lenta.

In quale fase si trova il lavoro quando sembra lento

Gli strumenti di backup attraversano fasi: scoprire i file, leggerli e calcolarne gli hash, comprimere, cifrare, caricare e poi verificare. Ogni fase ha il proprio collo di bottiglia e solo alcune toccano la rete. Uno strumento che non riporta ancora alcuna fase ti sta dicendo che non ha finito di scansionare.

Un lavoro che passa venti minuti a preparare un milione di file piccoli non accelererà quando il tunnel diventerà più veloce. Un lavoro che satura il collegamento in uscita è un problema di capacità con una soluzione diversa. Leggi l'output di avanzamento mentre si verifica il ritardo, annota la fase e scrivi il timestamp, perché la fase al momento della lamentela è l'unica che conta. I file piccoli si comportano anche diversamente da un oggetto grande, perché dominano i viaggi di andata e ritorno per file e il trasferimento non raggiunge mai un ritmo stabile. Confronta ciò che è confrontabile prima di trarre conclusioni sul tunnel.

Un endpoint pubblico e un NAS privato falliscono in modo diverso

Un servizio di backup pubblico porta la propria connessione applicativa autenticata, e il tunnel è un solo salto su un percorso più lungo. Un NAS privato di solito dipende da quel tunnel per la raggiungibilità di base della tua rete. Questa differenza decide se scollegare è una linea di base valida o un test del nulla.

Nel caso pubblico, lo stesso lavoro su un'altra route può essere un confronto equo quando la policy lo consente. Nel caso privato, rimuovere il tunnel non lascia alcuna route verso il server, quindi il risultato descrive il percorso che hai eliminato e non quello che usi.

Un blocco è un guasto diverso da un trasferimento lento

La terza colonna di quella tabella decide se un test di stabilità può essere eseguito, perché una linea di base che rimuove il tunnel ha senso solo dove esiste un altro percorso. Con una linea di base utilizzabile, guarda la forma del guasto invece del tasso medio. Un caricamento basso ma costante indica capacità, mentre un lavoro che si blocca e riparte indica interruzione, autenticazione o un singolo file problematico. Questi due producono lamentele quasi identiche e riparazioni completamente diverse.

I nuovi tentativi distorcono ogni misura, perché i byte sul filo possono essere più numerosi della quantità realmente cambiata. Leggi il comportamento di ripresa prima di interrompere di nuovo il lavoro per vedere cosa succede, perché i caricamenti frammentati ripristinabili si riprendono a poco costo e i riavvii dell'intero file no. Un tunnel che si riconnette ogni pochi minuti sembra anche un problema di larghezza di banda quando in realtà è un problema di stabilità. L'MTU del percorso peggiora la cosa, perché un tunnel che riduce il carico utile blocca i segmenti grandi mentre quelli piccoli passano.

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

Un solo caricamento può affamare tutti gli altri flussi

Un caricamento che riempie il collegamento in uscita rende le chiamate e la navigazione non reattive, e il backup raramente è l'unica cosa che se lo contende. Un secondo client di sincronizzazione produce lo stesso sintomo da solo. Prima di dare la colpa al tunnel, guarda cos'altro sta caricando.

Usa la pianificazione o il limite di larghezza di banda documentato dallo strumento invece di lottare per il throughput di punta; lasciare margine per il lavoro interattivo di solito vale più degli ultimi punti percentuali. Poi controlla a cosa si applica davvero il limite, perché alcuni strumenti limitano per file, altri l'intera esecuzione e altri ignorano del tutto il costo dei file piccoli. Un limite che non corrisponde al carico di lavoro non cambia nulla. Anche lo split tunneling merita sospetto qui, perché escludere il launcher dal tunnel non esclude il servizio ausiliario che esegue il caricamento. Rclone, per esempio, pubblica sia i limiti di trasferimento sia il comportamento dei tentativi nella sua documentazione, il che lo rende un riferimento utile su cosa dovrebbe controllare un limite.

Chiudi con un ripristino, non con un test di velocità

Un caricamento completato non è un backup finché qualcosa non ne viene ripristinato. Verifica che esista la versione attesa, poi ripristina un file rappresentativo con la procedura documentata dallo strumento. Conserva le informazioni di recupero altrove rispetto alla macchina o al profilo che potresti perdere, e non buttare mai un backup funzionante solo per tenere in ordine un esperimento.

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

Ripeti sia il trasferimento sia il ripristino dopo la modifica della rete, così che il miglioramento risulti al servizio del backup e non solo di uno spostamento più rapido dei dati. È quella seconda esecuzione a chiudere il ticket. Un trasferimento più veloce con un ripristino non testato è un modo più lento di restare senza protezione.