Les còpies al núvol van lentes per la VPN: troba la fase real
Una còpia lenta pot estar escanejant, calculant hashes o reintentant, no transferint. Compara la fase, el tipus de destinació i la restauració abans de canviar rutes.
Una còpia de seguretat que s'arrossega per una VPN convida a l'experiment obvi de desconnectar el túnel i tornar a mesurar. Aquest experiment sovint respon una altra pregunta, perquè la feina pot haver estat calculant hashes o esperant un reintent en lloc de moure bytes. Separa primer les fases i la queixa es converteix en una prova concreta amb un resultat esperat concret. La ruta només esdevé candidata quan la fase de transferència és la que realment va lenta.
En quina fase és la feina quan sembla lenta
Les eines de còpia passen per fases: descobrir fitxers, llegir-los i calcular-ne els hashes, comprimir, xifrar, pujar i després verificar. Cada fase té el seu coll d'ampolla, i només algunes toquen la xarxa. Una eina que encara no informa de cap fase t'està dient que no ha acabat d'escanejar.
Una feina que passa vint minuts preparant un milió de fitxers petits no s'accelerarà quan el túnel vagi més ràpid. Una feina que satura l'enllaç de pujada és un problema de capacitat amb una solució diferent. Llegeix la sortida de progrés mentre dura el retard, anota la fase i escriu la marca de temps, perquè la fase en el moment de la queixa és l'única que importa. Els fitxers petits també es comporten diferentment d'un objecte gran, ja que hi dominen els viatges d'anada i tornada per fitxer i la transferència no arriba mai a un ritme estable. Compara el comparable abans de treure conclusions sobre el túnel.
Un extrem públic i un NAS privat fallen de manera diferent
Un servei de còpia públic porta la seva pròpia connexió d'aplicació autenticada, i el túnel és un salt en un camí més llarg. Un NAS privat normalment depèn d'aquest túnel per a l'abast bàsic de la teva xarxa. Aquesta diferència decideix si desconnectar és una línia base vàlida o una prova de res.
En el cas públic, la mateixa feina per una altra ruta pot ser una comparació justa quan la política ho permet. En el cas privat, treure el túnel no deixa cap ruta cap al servidor, així que el resultat descriu el camí que has eliminat, no el que fas servir.
| 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 |
Una aturada és un fracàs diferent d'una transferència lenta
La tercera columna d'aquella taula decideix si una prova d'estabilitat pot funcionar, perquè una línia base que elimina el túnel només té sentit allà on existeix un altre camí. Amb una línia base útil, mira la forma del fracàs i no el ritme mitjà. Una pujada baixa però constant apunta a capacitat, mentre que una feina que s'atura i es reinicia apunta a interrupció, autenticació o un fitxer problemàtic. Aquestes dues produeixen queixes gairebé idèntiques i reparacions completament diferents.
Els reintents distorsionen qualsevol mesura, ja que els bytes a la xarxa poden ser més grans que la quantitat que ha canviat realment. Llegeix el comportament de represa abans de tornar a interrompre la feina per veure què passa, perquè les pujades fragmentades represes es recuperen barat i els reinicis de fitxer sencer no. Un túnel que es reconnecta cada pocs minuts també sembla un problema d'amplada de banda quan en realitat és un problema d'estabilitat. L'MTU del camí ho agreuja, ja que un túnel que redueix la càrrega útil bloqueja els segments grans mentre els petits passen.
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com
Una pujada pot afamar tots els altres fluxos
Una pujada que omple l'enllaç de pujada deixa les trucades i la navegació sense resposta, i la còpia poques vegades és l'única cosa que hi competeix. Un segon client de sincronització produeix el mateix símptoma pel seu compte. Abans de culpar el túnel, mira què més s'està pujant.
Fes servir la programació o el límit d'amplada de banda que l'eina documenta en lloc de lluitar pel pic de rendiment; deixar marge per a la feina interactiva sol valer més que els últims percentatges. Després comprova a què s'aplica realment el límit, perquè algunes eines limiten per fitxer, d'altres limiten tota l'execució i d'altres ignoren del tot el cost dels fitxers petits. Un límit que no encaixa amb la càrrega no canvia res. El túnel dividit també mereix sospita aquí, perquè excloure el llançador del túnel no exclou el servei auxiliar que fa la pujada. Rclone, per exemple, publica tant els límits de transferència com el comportament dels reintents a la seva documentació, cosa que el converteix en una referència útil sobre què hauria de controlar un límit.
Acaba amb una restauració, no amb una prova de velocitat
Una pujada completada no és una còpia fins que alguna cosa se'n restaura. Confirma que existeix la versió esperada i després restaura un fitxer representatiu amb el procediment que l'eina documenta. Guarda la informació de recuperació en un lloc diferent de la màquina o el perfil que pots perdre, i no llencis mai una còpia que funciona només per mantenir net un experiment.
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts
Repeteix tant la transferència com la restauració després del canvi de xarxa, perquè la millora es vegi al servei de la còpia i no només de moure dades més de pressa. Aquesta segona execució és la que tanca el tiquet. Una transferència més ràpida amb una restauració no provada és una manera més lenta de quedar sense protecció.