Почему копирование базы в облако выполняется слишком долго?
Многие считают, что включение ZIP-сжатия должно ускорить резервное копирование, ведь после сжатия в облако передается значительно меньше данных. На практике это не всегда так.
Пример основан на реальной задаче пользователя: база MSSQL объемом около 160 ГБ копировалась на Яндекс Диск в течение 6 - 7 часов.
Исходная проблема
Необходимо выполнять копирование базы данных Microsoft SQL Server объемом около 160 ГБ в Яндекс Диск с использованием ZIP-сжатия. Однако полное выполнение задачи занимает 6 - 7 часов, и непонятно, почему процесс длится так долго.
Сценарий использования
Я выполняю резервное копирование MS SQL размером около 160 ГБ в облачное хранилище Яндекс Диска. Несмотря на то, что после ZIP-сжатия размер копии уменьшился о 30 ГБ, выполнение задачи занимает 6 - 7 часов. Почему процесс бэкапа выполняется так долго?
Решение
Продолжительность бэкапа в облачное хранилище зависит не только от объема данных и скорости интернет-соединения. Во время выполнения задачи последовательно выполняется несколько этапов, каждый из которых влияет на общее время резервного копирования. Существенное влияние также оказывают обработка данных, создание архива и взаимодействие с облачным сервисом.
Если итоговый архив занимает значительно меньше исходной базы данных, это не означает, что программа только загружает готовый файл в облако. Резервное копирование включает несколько последовательных этапов:
- подготовку задачи, подключение к Microsoft SQL Server и вычисление объема данных;
- создание согласованного снимка базы данных (VSS-снимка);
- чтение и обработку данных базы MSSQL;
- формирование резервной копии и ZIP-архива;
- передачу архива в Яндекс Диск;
- ожидание подтверждения загрузки и завершения обработки файла облачным сервисом.
Почему ZIP-сжатие не всегда ускоряет резервное копирование
Независимо от итогового размера архива программа Handy Backup должна прочитать и обработать весь исходный объем базы данных. Например, если база занимает около 160 ГБ, все 160 ГБ участвуют в обработке, даже если после сжатия размер архива уменьшился до нескольких десятков гигабайт.
Сам процесс ZIP-сжатия также требует времени и вычислительных ресурсов. Его продолжительность зависит от объема и структуры данных, производительности процессора и скорости накопителя. Итоговый размер зависит от содержимого базы данных. Текст, таблицы и повторяющиеся данные обычно сжимаются лучше, чем изображения, видео, PDF-файлы и уже готовые архивы.
Ниже приведены примерные значения, показывающие, как содержимое базы данных может влиять на размер архива и общую продолжительность выполнения задачи.
| Содержимое базы данных | Размер после ZIP-сжатия (пример) | Возможная продолжительность выполнения задачи* |
| Преимущественно текстовые данные, таблицы и индексы | 30–60 ГБ | 4–7 часов |
| Смешанные данные: текст, документы и изображения | 80–120 ГБ | 7–10 часов |
| Уже сжатые данные: JPEG, PDF, ZIP, видео и другие бинарные объекты | 140–160 ГБ | 10–14 часов и более |
* Примерная оценка для базы данных объемом около 160 ГБ. Время включает чтение исходных данных, формирование резервной копии, ZIP-сжатие, передачу архива в Яндекс Диск и завершающую обработку файла облачным сервисом. Фактическая продолжительность может отличаться как в большую, так и в меньшую сторону. Даже одна и та же задача при одинаковых настройках не обязательно будет каждый раз выполняться за одинаковое время.
Что влияет на скорость передачи архива в Яндекс Диск
Дополнительное время может занимать взаимодействие с облачным хранилищем. После формирования ZIP-архива программа передает его в Яндекс Диск через API. В зависимости от размера архива и скорости ответа облачного сервиса этот этап также может занимать продолжительное время. После завершения загрузки облачный сервис может еще некоторое время регистрировать и обрабатывать полученный файл, прежде чем подтвердить успешное завершение операции.
На продолжительность передачи также могут влиять:
- фактическая скорость исходящего интернет-канала;
- нагрузка на локальную сеть;
- прокси-серверы и дополнительные межсетевые экраны;
- текущая доступность серверов Яндекс Диска;
- время регистрации и обработки файла на стороне облачного сервиса.
Результат
Резервное копирование базы MSSQL объемом около 160 ГБ в Яндекс Диск может занимать 6 - 7 часов и более, даже если получившийся ZIP-архив значительно меньше исходной базы. Программа должна обработать весь исходный объем данных, создать архив, передать его в облако и дождаться завершения операций на стороне сервиса.
Поэтому длительный интервал между началом обработки базы и завершением задачи не обязательно указывает на ошибку. Он может включать чтение и обработку данных базы, создание ZIP-архива, передачу данных в Яндекс Диск, ожидание ответов сервера и завершающую обработку файла облачным сервисом.
Если в процессе резервного копирования возникли ошибки или время выполнения задачи кажется необычно большим, напишите нам на support@handybackup.ru. Приложите логи выполнения задачи и опишите весь процесс создания задачи: что копируете и куда, какие параметры используются (например, ZIP-сжатие). Это поможет нам проанализировать ситуацию и, по возможности, определить причину.
Связанные страницы: