Облачные резервные копии медленные через 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

Повторите и передачу, и восстановление после изменения сети, чтобы улучшение доказанно служило резервному копированию, а не только более быстрому перемещению данных. Именно второй запуск закрывает заявку. Более быстрая передача с непроверенным восстановлением — это более медленный способ остаться без защиты.