A felhőmentések lassúak a VPN-en: találja meg a valódi szakaszt

A VPN-en átvonszoló mentés kínálja a kézenfekvő kísérletet: szüntesse meg az alagutat, és mérjen újra. Ez a kísérlet gyakran más kérdésre válaszol, mert a feladat talán fájlokat hashelt vagy újrapróbálkozásra várt a bájtok mozgatása helyett. Először válassza szét a szakaszokat, és a panasz konkrét tesztté válik konkrét várható eredménnyel. Az útvonal csak akkor lesz jelölt, ha valóban az átviteli szakasz a lassú.

Melyik szakaszban van a feladat, amikor lassúnak tűnik

A mentőeszközök szakaszokon mennek át: fájlok felderítése, olvasásuk és hash-elésük, tömörítés, titkosítás, feltöltés, majd ellenőrzés. Minden szakasznak megvan a maga szűk keresztmetszete, és csak néhány érinti egyáltalán a hálózatot. Egy eszköz, amely még egyetlen szakaszt sem jelent, azt mondja, hogy nem fejezte be a szkennelést.

Egy feladat, amely húsz percet tölt egymillió kis fájl előkészítésével, nem lesz gyorsabb, ha az alagút gyorsabb lesz. Egy feladat, amely telíti a feltöltési sávot, kapacitásprobléma, más megoldással. Olvassa a folyamat kimenetét a késedelem alatt, jegyezze fel a szakaszt és írja le az időbélyeget, mert a panasz pillanatában a szakasz az egyetlen, amely számít. A kis fájlok másként viselkednek, mint egy nagy objektum, mert a fájlonkénti oda-vissza utak uralkodnak, és az átvitel soha nem ér el állandó sebességet. Hasonlítsa össze a hasonlót a hasonlóval, mielőtt következtetéseket von le az alagútról.

Egy nyilvános végpont és egy magán NAS másként hibázik

A nyilvános mentési szolgáltatás saját hitelesített alkalmazáskapcsolatot hordoz, az alagút pedig egy ugrás a hosszabb úton. A magán NAS általában ettől az alagúttól függ a hálózat alapvető eléréséhez. Ez a különbség dönti el, hogy a leválasztás érvényes alapvonal-e, vagy a semmi tesztje.

A nyilvános esetben ugyanaz a feladat más útvonalon tisztességes összehasonlítás lehet, ha a szabályzat engedi. A magán esetben az alagút eltávolítása semmilyen útvonalat nem hagy a kiszolgálóhoz, így az eredmény a törölt útvonalat írja le, nem azt, amelyet használ.

A megakadás más hiba, mint a lassú átvitel

A táblázat harmadik oszlopa dönti el, egyáltalán lefuthat-e stabilitási teszt, mert az alagutat eltávolító alapvonal csak ott jelent valamit, ahol létezik másik út. Használható alapvonallal a hiba alakját figyelje, ne az átlagsebességét. Az alacsony, de egyenletes feltöltés kapacitásra utal, míg a megakadó és újrainduló feladat megszakításra, hitelesítésre vagy egyetlen problémás fájlra. Ez a kettő szinte azonos panaszokat és teljesen különböző javításokat eredményez.

Az újrapróbálkozások minden mérést torzítanak, mert a vezetéken lévő bájtok többek lehetnek, mint amennyi ténylegesen megváltozott. Olvassa el a folytatási viselkedést, mielőtt ismét megszakítja a feladatot, hogy lássa, mi történik, mert a darabolt, folytatható feltöltések olcsón helyreállnak, a teljes fájl újraindítása viszont nem. Az az alagút, amely néhány percenként újracsatlakozik, szintén sávszélesség-problémának tűnik, amikor valójában stabilitási probléma. Az útvonal MTU-ja tovább súlyosbítja, mert a hasznos terhet csökkentő alagút megakasztja a nagy szegmenseket, míg a kicsik átmennek.

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

Egy feltöltés kiéheztethet minden más folyamot

A feltöltési sávot megtöltő feltöltés válaszképtelenné teszi a hívásokat és a böngészést, és a mentés ritkán az egyetlen, amelyik verseng érte. Egy második szinkronizáló kliens maga is ugyanazt a tünetet okozza. Mielőtt az alagutat okolná, nézze meg, mi más tölt fel.

Használja az eszköz által dokumentált ütemezést vagy sávszélesség-korlátot a csúcsátvitelért vívott harc helyett; a helyet hagyni az interaktív munkának általában többet ér az utolsó százalékoknál. Utána ellenőrizze, mire vonatkozik valójában a korlát, mert egyes eszközök fájlonként, mások a teljes futásra korlátoznak, és vannak, amelyek teljesen figyelmen kívül hagyják a kis fájlok többletköltségét. A munkaterheléshez nem illő korlát semmit sem változtat. A megosztott alagút itt is gyanús, mert az indító kizárása az alagútból nem zárja ki a feltöltést végző segédszolgáltatást. Az Rclone például az átviteli korlátokat és az újrapróbálkozási viselkedést is közzéteszi a dokumentációjában, ami hasznos hivatkozássá teszi arra nézve, mit kellene egy korlátnak szabályoznia.

Visszaállítással fejezze be, ne sebességteszttel

A befejezett feltöltés nem mentés addig, amíg valamit vissza nem állítanak belőle. Erősítse meg, hogy a várt verzió létezik, majd állítson vissza egy reprezentatív fájlt az eszköz által dokumentált eljárással. A helyreállítási információt máshol tartsa, mint a gép vagy profil, amelyet elveszíthet, és soha ne dobjon ki működő mentést csak azért, hogy a kísérlet rendben maradjon.

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

Ismételje meg az átvitelt és a visszaállítást is a hálózati változás után, hogy a javulás bizonyítottan a mentést szolgálja, és ne csak a gyorsabb adatmozgatást. A második futás az, amely lezárja a jegyet. A gyorsabb átvitel tesztelatlan visszaállítással lassabb módja annak, hogy védelem nélkül maradjon.