Резервная копия защищает данные только тогда, когда успевает завершиться и может быть восстановлена в допустимый срок. На небольшом VPS дамп, сжатие и выгрузка конкурируют с рабочим приложением за CPU, память, диск и сеть. Окно копирования нужно рассчитывать как эксплуатационную операцию, а не назначать случайным cron на ночь.
Фото обложки: David Monniaux. Photo taken by myself with a cellular phone. Copyright © 2005; Paris servers DSC00190.jpg, CC BY-SA 3.0. Уменьшение размеров и преобразование в WebP; кадрирование не выполнялось. Тематический снимок не изображает инфраструктуру упомянутых провайдеров.
Разделите три временных требования
| Понятие | Что определяет | Пример вопроса |
|---|---|---|
| Окно копирования | Когда и сколько длится создание/доставка копии | Успевает ли задание до следующего запуска? |
| RPO | Допустимая потеря изменений | Какой последний момент данных можно вернуть? |
| RTO | Допустимое время возврата принятого приложения | Сколько займут развёртывание, восстановление и проверка? |
Задание раз в сутки не гарантирует RPO ровно 24 часа: возможны ошибки, задержка копирования и несогласованность данных. Время скачивания архива тоже не равно RTO. После него остаются подготовка базы, возврат файлов, конфигурация и прикладная приёмка.
Разложите конвейер
Запишите этапы: получение согласованной точки, чтение источника, экспорт или физическая копия, сжатие, шифрование, передача и проверка. Некоторые этапы идут последовательно, другие перекрываются. Для перекрывающегося потока скорость ограничивает самое медленное звено, а память и временные данные требуют отдельного учёта.
Для MariaDB выбирают поддерживаемый метод по версии и движкам таблиц. Документация mariadb-backup разделяет создание, подготовку и восстановление физической копии. Случайное копирование работающего datadir не превращается в согласованный архив только потому, что его успели выгрузить.
Условный расчёт передачи
Пусть готовый архив имеет размер 30 ГиБ, а устойчивое измеренное чтение и передача дают 15 МиБ/с. Только перенос потребует примерно 30 × 1024 / 15 = 2 048 секунд, около 34 минут. Это учебный пример с условными величинами, а не скорость какого-либо провайдера.
К этому добавляются получение копии, подготовка, проверка и запас на повторные попытки. Если архив ещё сжимается на лету, фактическая скорость может определяться CPU. Если рабочая база одновременно активно пишет, чтение копии будет конкурировать за диск и способно увеличить задержку сайта.
Пиковое место на диске
Посчитайте источник, временный дамп, сжатый архив, предыдущую копию и служебный запас. Наличие места только для финального ZIP недостаточно. Некоторые инструменты создают дополнительные файлы во время подготовки или проверки; это нужно узнать на стенде.
Не отключайте старую копию автоматически в начале задания, если новая ещё не прошла проверку. Политика хранения должна учитывать неудачный запуск и необходимую глубину истории. Удаление единственного принятого архива ради освобождения места создаёт новый риск вместо решения бюджета.
Конкуренция с другими заданиями
На сервере с несколькими сайтами инвентаризируйте cron, импорты, сканирование, ротацию логов и генерацию изображений. Если все задачи назначены на 03:00, низкий пользовательский трафик не гарантирует свободный сервер. Важен общий профиль фоновых операций.
Разнесите задания по согласованному расписанию и исключите перекрытие следующего экземпляра с предыдущим. Блокировка запуска должна иметь понятное поведение при зависании и диагностике; простое накопление очередных копий повышает нагрузку. Не вводите новую тяжёлую систему только ради одного расписания, если есть подходящий штатный механизм.
Что измерять в пилоте
- Объём исходных данных и итогового архива.
- Время каждого этапа и общую длительность.
- Пик памяти, CPU и временного места.
- Изменение задержки приложения в тот же интервал.
- Скорость передачи с учётом реального маршрута.
- Ошибки, повторы и итог проверки копии.
Не превращайте пилот в стресс-тест рабочего VPS. Сначала используйте отдельную копию и консервативный режим. При появлении ошибок приложения, признаков OOM или нестабильности базы остановите новые тяжёлые операции и разберите причину.
Полное время восстановления
Отработайте возврат в независимую среду. В RTO входят получение доступа, создание окружения, загрузка архива, подготовка базы, импорт, файлы, конфигурация и проверка. Если ключ шифрования доступен только на потерянном сервере, красивый архив не решает задачу.
Для приложения с внешними API и очередью нужна изоляция тестового восстановления. Не допускайте повторной отправки платежей, писем и CRM-событий. Контрольная запись и вложение должны читаться после возврата, а не только присутствовать в списке файлов архива.
Рост данных и запас
Повторяйте расчёт после существенного роста каталога, медиа или истории заказов. Вчерашняя длительность не описывает следующий год эксплуатации. Храните ряд фактических результатов и предупреждайте о приближении к границе окна до того, как начнут пересекаться задания.
Сжатие сильнее не всегда дешевле: оно может сократить сеть ценой CPU и задержки сайта. Выбирайте режим по полному времени и влиянию на приложение. Сравнивайте одинаковые данные и считайте необходимые расходы хранения и выгрузки по актуальному тарифу.
FAQ
Ночью всегда безопасно копировать всё сразу?
Нет. В это время могут работать импорты и обслуживание других сайтов. Нужна карта общих заданий.
Успешный код завершения равен проверенной копии?
Он подтверждает выполнение определённого этапа. Нужны целостность, восстановление и прикладная приёмка.
Можно считать RTO по размеру архива?
Только как частичную оценку передачи. Остальные этапы нужно измерить отдельно.
Вывод
Рабочее резервирование укладывается в доступное окно, не разрушает обслуживание сайта и подтверждено возвратом приложения. Планируйте ресурсный бюджет всей цепочки и проверяйте его по фактическим результатам.
Для смежных задач: Как создать резервную копию WordPress и проверить восстановление, Как восстановить WordPress после неудачного обновления и не потерять новые данные, Заканчивается место на хостинге: диск, inode, архивы и безопасная очистка.
Источники и дата проверки
Сведения проверены 29.10.2026. Параметры услуги перед заказом нужно сверять повторно. Собственные замеры провайдера и контрольные обращения в поддержку не проводились.
