Автобэкапы на сервере: практические схемы и ошибки

Автобэкап, который лежит на том же сервере, что и сайт, не спасёт при отказе диска, краже сервера или шифровальщике. На практике важны не только расписание и инструмент, но и место хранения, состав копии и регулярная проверка восстановления. Ниже — три рабочих подхода для Linux-сервера: от простой локальной копии до отдельного хранилища.

Сначала определите, что именно нужно восстановить

Не складывайте всё подряд в архив, пока не решите, какой результат вам нужен после аварии. Для сайта на сервере обычно отдельно учитывают файлы приложения и загруженный контент, базу данных, конфигурацию веб-сервера и сведения, без которых нельзя запустить сервис. Каталоги с временными файлами и кешем часто можно восстановить иначе, но исключать их стоит только после проверки, что там нет пользовательских данных.

Состав зависит от приложения. Например, копия каталога сайта сама по себе не содержит данные из MySQL или PostgreSQL, если база хранится отдельно. А резервная копия базы не вернёт загруженные пользователями изображения.

• Файлы: код, пользовательские загрузки, нужные конфигурации.
• База данных: согласованная копия, сделанная подходящим для конкретной СУБД способом.
• Восстановление: инструкция, версии сервисов и перечень внешних зависимостей.

RPO — допустимая потеря данных во времени: если резервная копия создаётся раз в сутки, при аварии можно потерять почти сутки изменений. RTO — допустимое время, за которое сервис нужно вернуть в работу.

Три схемы: от простого к более надёжному

Для сравнения ниже рассматриваются обычный Linux-сервер, rsync 3.x и restic 0.17.x. Синтаксис и доступные возможности зависят от конкретной версии; перед внедрением сверяйте команды и параметры с документацией установленного инструмента.

Ни один вариант не освобождает от восстановления базы данных и проверки приложения. Наличие архива — не доказательство, что сайт запустится.

Как выбрать схему для своей нагрузки

Локальная копия: только дополнительный уровень

Копия на другом каталоге того же диска удобна для возврата удалённого файла, но это не полноценная защита. Если сервер доступен злоумышленнику с правами, позволяющими удалить рабочие данные, он часто сможет удалить и локальную копию. Используйте такой вариант как быстрый слой восстановления, а не как единственный бэкап.

rsync: когда нужно передавать файлы на другой сервер

rsync подходит для копирования каталогов между машинами, в том числе через SSH. Он сам по себе не превращает набор файлов в надёжную систему истории: если вы синхронизируете удаление, ошибочно удалённый файл может исчезнуть и из копии. Нужны отдельные снимки, версии или другая стратегия хранения старых состояний.

Для базы данных не стоит просто копировать файлы работающей СУБД обычной синхронизацией: полученный набор может оказаться несогласованным. Используйте штатный механизм резервного копирования вашей СУБД и отдельно проверяйте восстановление.

restic: когда нужна история и внешнее хранилище

restic создаёт снимки данных в репозитории и поддерживает хранение в разных типах хранилищ. Такой подход удобен, если нужно иметь несколько точек восстановления и не держать единственную копию рядом с исходными файлами. Репозиторий следует размещать отдельно от основного сервера; если храните его у облачного провайдера, проверьте ограничения по объёму и стоимости операций.

У шифрования есть практическая цена: без пароля репозитория восстановление может стать невозможным. Храните секрет отдельно от сервера и проверьте процедуру доступа к нему до аварии. Не включайте пароль в командную строку, скрипт или логи.

Резервная копия считается рабочей не в момент, когда задача завершилась без ошибки, а когда вы восстановили из неё нужные данные.

Что ломается чаще всего

• Заканчивается место. Резервное копирование падает или вытесняет рабочие данные. Настройте оповещение о свободном месте и проверьте, что срок хранения копий ограничен осмысленно.
• Копируется только сайт, но не база. Файлы восстановятся, а заказы и учётные записи — нет. Проверьте, как именно сохраняется база и как она загружается обратно.
• Копия доступна тем же учётным данным. Компрометация основного сервера может открыть путь к резервам. По возможности ограничьте права записи и отделите учётные данные хранилища.
• Не проверяется расписание. Задача могла завершаться с ошибкой неделями. Следите не только за запуском, но и за результатом, временем последней успешной копии и объёмом данных.
• Нет теста восстановления. Архив повреждён, пароль потерян или инструкция устарела. Периодически восстанавливайте копию в отдельную среду, не поверх рабочего сайта.

Когда что выбирать

Если вы защищаетесь только от случайного удаления отдельного файла, локальная копия удобна как быстрый дополнительный слой. Если есть второй сервер и важна простая передача каталогов — рассмотрите rsync, но отдельно обеспечьте историю и защиту от удаления. Если нужны зашифрованные снимки во внешнем хранилище и несколько точек восстановления, оцените restic и заранее решите, где безопасно хранить секрет репозитория.

Критерий выбора — не популярность инструмента, а сценарий отказа. Ответьте на три вопроса: сколько данных допустимо потерять, как быстро нужно восстановиться и что произойдёт с копией, если основной сервер полностью скомпрометируют.

Что делать дальше

Составьте список данных, выберите одну копию вне основного сервера и зафиксируйте порядок восстановления. Затем проведите тест: разверните копию в изолированной среде, проверьте базу и откройте ключевые страницы приложения. После этого настройте оповещения о сбоях, свободном месте и давности последней успешной копии. Периодически измеряйте не только длительность бэкапа, но и фактическое время восстановления — именно оно покажет, укладываетесь ли вы в свой RTO.