Хмарні резервні копії повільні через 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

Повторіть і передачу, і відновлення після зміни мережі, щоб покращення доведено служило резервному копіюванню, а не лише швидшому переміщенню даних. Саме другий запуск закриває заявку. Швидша передача з неперевіреним відновленням — це повільніший спосіб залишитися без захисту.