Многие владельцы VPS считают, что если они сделали снапшот, то резервная копия у них уже есть. На деле снапшот и полноценный бэкап похожи лишь внешне и защищают от разных проблем. Снапшот удобен, чтобы быстро откатить систему назад, а бэкап — это независимая копия, которая позволит восстановиться, даже если сервер исчез целиком или данные были повреждены несколько дней назад. Непонимание этой разницы обычно обнаруживается в самый неудачный момент — когда копия действительно понадобилась.
Что такое снапшот и как он работает
Снапшот фиксирует состояние диска виртуальной машины в конкретный момент. Чаще всего он не копирует данные целиком: система виртуализации «замораживает» текущие блоки и записывает последующие изменения отдельно. Поэтому снапшот создаётся за секунды или минуты, а вернуть сервер в это состояние можно очень быстро. Например, сделать снапшот перед обновлением операционной системы или сменой версии PHP — хорошая привычка: если что-то сломается, через несколько минут вы снова в рабочем состоянии.
Однако снапшот обычно хранится в той же инфраструктуре, нередко в той же системе хранения. Если выйдет из строя дисковый массив, в аккаунт проникнет злоумышленник или сервер удалят, снапшот может пропасть вместе с ним. Кроме того, снапшот работающего сервера является «crash-consistent»: это похоже на состояние после внезапного отключения питания. Файловая система обычно это переносит, но транзакции базы данных, ещё не записанные из памяти на диск, могут сохраниться не полностью.
Почему бэкап — отдельное понятие
Под бэкапом понимается копия данных, вынесенная в другое место и не зависящая от сервера. Она может храниться на другом сервере, в объектном хранилище (S3-совместимом сервисе) или на диске в офисе. Хороший бэкап содержит несколько версий: вчерашнюю, недельной давности и месячной давности. Это критично, потому что многие проблемы замечают не сразу. Если сайт взломали и в файлы внедрили вредоносный код, это иногда обнаруживается через неделю-две, и чистой оказывается только старая версия.
Бэкап обычно сохраняет не весь диск, а то, что действительно нужно: файлы сайта, дамп базы данных, конфигурационные файлы (/etc/nginx, задания cron, настройки SSL и приложения). Операционную систему легко переустановить, а ваши данные неповторимы.
Сравнение в одной таблице
| Критерий | Снапшот | Бэкап |
|---|---|---|
| Скорость создания | Очень быстро, секунды или минуты | Минуты или часы в зависимости от объёма |
| Где хранится | Обычно в той же инфраструктуре | На отдельном сервере или в хранилище |
| Что сохраняется | Состояние всего диска | Выбранные файлы и дамп базы |
| Если сервер потерян | Часто теряется вместе с ним | Остаётся доступным |
| Лучшее применение | Быстрая точка отката перед изменениями | Долгосрочная защита и полное восстановление |
Как правильно копировать базу данных
Просто копировать файлы работающей базы MySQL или PostgreSQL опасно: во время копирования они продолжают меняться. Правильный путь — делать дамп штатными средствами СУБД. Для таблиц InnoDB параметр --single-transaction даёт согласованную копию без блокировки базы, поэтому сайт продолжает работать.
# MySQL / MariaDB
mysqldump --single-transaction --routines --triggers -u backup -p shop_db | gzip > /backup/shop_db_$(date +%F).sql.gz
# PostgreSQL
pg_dump -U postgres -Fc clinic_db > /backup/clinic_db_$(date +%F).dumpПосле создания дампа его нужно вынести за пределы сервера. Самый простой способ — rsync по SSH на другой сервер. Если нужны шифрование, версии и дедупликация, удобны инструменты вроде restic или borg.
# перенос файлов и дампов на другой сервер
rsync -az --delete /backup/ backupuser@backup.example.uz:/srv/backups/vps1/
# зашифрованная версионная копия с restic
restic -r sftp:backupuser@backup.example.uz:/srv/restic init
restic -r sftp:backupuser@backup.example.uz:/srv/restic backup /var/www /etc /backup
restic -r sftp:backupuser@backup.example.uz:/srv/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneПрактический пример: интернет-магазин в Ташкенте
Представим небольшой магазин бытовой техники в Ташкенте с сайтом misol.uz на VPS: WooCommerce, база MySQL и несколько десятков заказов в день. Каждую ночь в 03:00 cron снимает дамп базы и вместе с /var/www и /etc отправляет его через restic на резервный сервер в другом городе. Restic хранит 7 ежедневных, 4 еженедельных и 6 ежемесячных копий. Перед каждым обновлением плагинов или PHP дополнительно делается снапшот.
# crontab -e
0 3 * * * /usr/local/bin/nightly-backup.sh >> /var/log/nightly-backup.log 2>&1Однажды после установки нового платёжного плагина сайт показал белый экран. Администратор за пять минут откатил сервер по снапшоту к утреннему состоянию. В другой раз сотрудник неверным SQL-запросом испортил таблицу цен, и это заметили лишь через два дня. Снапшот здесь бы не помог: он был сделан до обновления, и откат уничтожил бы новые заказы. Выручил бэкап трёхдневной давности: администратор восстановил из старого дампа только одну таблицу, не трогая остальные данные.
Правило 3-2-1 и проверка восстановления
Широко известный принцип резервирования называется правилом 3-2-1: держите минимум три копии данных на двух разных типах носителей, причём одну из них — в другом месте. Для VPS это может выглядеть так: рабочие данные на самом сервере, репозиторий restic на другом сервере и периодически выгружаемая копия на офисный диск или в другое облако.
Чаще всего забывают о проверке восстановления. Бэкап, из которого нельзя восстановиться, бэкапом не является. Раз в месяц поднимайте сайт из последней копии на тестовом сервере: открывается ли дамп, все ли файлы на месте, запускается ли сайт. Также настройте уведомления об ошибках скрипта резервирования, иначе он может молча не работать месяцами.
# восстановить последнюю копию во временную папку и проверить
restic -r sftp:backupuser@backup.example.uz:/srv/restic restore latest --target /tmp/restore-test
gunzip -t /tmp/restore-test/backup/shop_db_*.sql.gz && echo "dump OK"Когда что использовать
Используйте снапшот как краткосрочную страховку перед крупным изменением и удаляйте его, убедившись, что всё работает: долго хранящиеся снапшоты занимают место и в некоторых системах замедляют диск. Бэкап же стройте постоянным, автоматическим и хранящимся вне сервера. Если ваш VPS размещён в sayt.uz, вопросы о снапшотах и резервировании можно уточнить через кабинет или техническую поддержку, но независимую копию собственных данных всё равно лучше держать под своим контролем.
Если коротко, снапшот — это кнопка «шаг назад», а бэкап — гарантия «вернусь, даже если всё пропало». Используя оба инструмента вместе, владелец сервера защищён и от мелких ошибок, и от серьёзных аварий.