Облачните резервни копия са бавни през VPN: открийте истинската фаза

Резервно копие, което пълзи през VPN, подтиква към очевидния експеримент да изключите тунела и да измерите отново. Този експеримент често отговаря на друг въпрос, защото задачата може да е хеширала файлове или да е чакала повторен опит, вместо да мести байтове. Отделете първо фазите и оплакването се превръща в конкретен тест с конкретен очакван резултат. Маршрутът става кандидат само когато бавна е именно фазата на прехвърляне.

В коя фаза е задачата, когато изглежда бавна

Инструментите за резервни копия минават през фази: откриване на файловете, четене и хеширане, компресиране, криптиране, качване, след това проверка. Всяка фаза има своето тясно място и само някои от тях изобщо докосват мрежата. Инструмент, който още не отчита фаза, ви казва, че не е приключил сканирането.

Задача, която отделя двадесет минути за подготовка на милион малки файла, няма да се ускори, когато тунелът стане по-бърз. Задача, която насища изходящия канал, е проблем с капацитета с различно решение. Четете изхода за напредъка, докато трае забавянето, отбележете фазата и запишете часа, защото фазата по време на оплакването е единствената, която има значение. Малките файлове също се държат различно от един голям обект, тъй като преобладават обръщенията за всеки файл и трансферът никога не достига стабилна скорост. Сравнявайте подобно с подобно, преди да правите изводи за тунела.

Публична крайна точка и частен NAS се провалят по различен начин

Публичната услуга за резервни копия носи собствена удостоверена връзка на приложението, а тунелът е едно прескачане по по-дълъг път. Частният NAS обикновено зависи от този тунел за базова достъпност до вашата мрежа. Тази разлика решава дали изключването е валидна базова линия, или тест на нищо.

За публичния случай същата задача по друг маршрут може да е честно сравнение, когато политиката позволява. За частния случай премахването на тунела не оставя никакъв път до сървъра, така че резултатът описва пътя, който сте изтрили, а не този, който използвате.

Застоят е различен отказ от бавното прехвърляне

Третата колона на тази таблица решава дали изобщо може да се проведе тест за стабилност, защото базова линия, която премахва тунела, има смисъл само там, където съществува друг път. С използваема базова линия наблюдавайте формата на отказа, а не средната му скорост. Ниско, но стабилно качване сочи към капацитет, докато задача, която застоява и се рестартира, сочи към прекъсване, удостоверяване или един проблемен файл. Тези две дават почти идентични оплаквания и напълно различни поправки.

Повторните опити изкривяват всяко измерване, тъй като байтовете по мрежата може да са повече от количеството, което действително се е променило. Прочетете поведението при възобновяване, преди отново да прекъснете задачата, за да видите какво става, защото разпределеното възобновяемо качване се възстановява евтино, а рестартирането на целия файл — не. Тунел, който се свързва наново на всеки няколко минути, също изглежда като проблем с честотната лента, когато всъщност е проблем със стабилността. MTU на пътя допълнително усложнява това, защото тунел, който намалява полезния товар, блокира големите сегменти, докато малките минават.

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

Едно качване може да изгладнее всеки друг поток

Качване, което запълва изходящия канал, прави разговорите и разглеждането неотзивчиви, а резервното копие рядко е единственото, което се конкурира за него. Втори клиент за синхронизация създава същия симптом сам по себе си. Преди да обвините тунела, вижте какво още качва.

Използвайте графика или ограничението на честотната лента, което инструментът документира, вместо да се борите за пикова пропускателна способност; оставянето на резерв за интерактивна работа обикновено струва повече от последните няколко процента. След това проверете за какво всъщност се прилага ограничението, защото някои инструменти ограничават на файл, други на цялото изпълнение, а трети напълно пренебрегват разходите за малки файлове. Ограничение, което не отговаря на натоварването, не променя нищо. Разделеното тунелиране също заслужава подозрение тук, защото изключването на стартера от тунела не изключва помощната услуга, която извършва качването. Rclone например публикува както лимитите за трансфер, така и поведението при повторни опити в своята документация, което го прави полезен ориентир за това какво трябва да контролира ограничението.

Завършете с възстановяване, а не с тест за скорост

Завършеното качване не е резервно копие, докато нещо не се възстанови от него. Потвърдете, че очакваната версия съществува, след което възстановете представителен файл по процедурата, която инструментът документира. Пазете информацията за възстановяване някъде извън машината или профила, които може да загубите, и никога не изхвърляйте работещо резервно копие само за да остане експериментът подреден.

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

Повторете и трансфера, и възстановяването след промяната в мрежата, така че подобрението да покаже, че служи на резервното копие, а не само на по-бързото местене на данни. Именно второто изпълнение затваря заявката. По-бърз трансфер с непроверено възстановяване е по-бавен начин да останете без защита.