Бэкап нужен не для того, чтобы он был, а для того, чтобы из него можно было восстановиться в худший день. Поэтому администратор решает тут не одну задачу, а связку: что именно копировать, как часто, куда складывать копии, сколько поколений хранить и как доказать, что восстановление реально работает. В этом уроке разберем стратегии (полный, инкрементальный, дифференциальный), ротацию поколений, рабочие инструменты (rsync, tar, dd, dump/restore, mt) и два правила, которые экономят карьеру: 3-2-1 и обязательная проверка восстановления.
Как это работает
Три стратегии отличаются ответом на вопрос "относительно чего считаем изменения". Полный бэкап (full) копирует все данные целиком - долго и объемно, зато восстановление в один шаг. Дифференциальный (differential) хранит все, что изменилось с момента последнего ПОЛНОГО бэкапа: каждый день растет, но для восстановления нужны только два файла - последний full плюс последний differential. Инкрементальный (incremental) хранит изменения с момента ЛЮБОГО предыдущего бэкапа (full или incremental): копии маленькие и быстрые, но для восстановления нужна вся цепочка от full до нужной точки, и обрыв одного звена ломает все, что после него.
Классический способ отслеживать "что изменилось" - это уровни dump (0 - полный, 1-9 - инкременты относительно меньшего уровня) или флаг архивации. В мире файлов проще: tar умеет инкрементальный режим через снапшот-файл, а rsync сравнивает дерево по размеру и времени модификации (mtime) и переносит только дельту.
Ротация - это сколько поколений копий вы держите и по какому расписанию перезаписываете носители. Популярная схема "дед-отец-сын" (GFS): ежедневные копии (сыновья) хранятся неделю, еженедельные (отцы) - месяц, ежемесячные (деды) - год. Так вы балансируете между объемом хранения и глубиной отката во времени.
Правило 3-2-1: держите минимум 3 копии данных, на 2 разных типах носителей, причем 1 копия - вне площадки (offsite). Это защищает не от сбоя диска, а от пожара, шифровальщика и удаления "по ошибке rm -rf". И главное: бэкап, который никто не пробовал восстановить, бэкапом не является. Это просто набор файлов с неизвестным статусом.
Команды и примеры
rsync - основной инструмент для файловых бэкапов и зеркал. Ключ -a (archive) сохраняет права, владельцев, время и симлинки; --delete убирает на приемнике то, чего уже нет на источнике.
Код: Выделить всё
rsync -aAX --delete /home/ /backup/home/
# -A ACL, -X xattrs; --delete делает точное зеркало
# по сети поверх SSH
rsync -aAX --delete -e ssh /var/www/ user@backup.local:/srv/www/
Код: Выделить всё
rsync -aAX --delete --link-dest=/backup/2026-06-12 \
/home/ /backup/2026-06-13/
# одинаковые файлы - hardlink на вчерашнюю копию, занимают место один раз
Код: Выделить всё
# полный (снапшот создается заново)
tar --listed-incremental=/var/backup/snap.snar \
-czf /var/backup/full-2026-06-13.tar.gz /home
# следующий запуск с тем же .snar даст инкремент
tar --listed-incremental=/var/backup/snap.snar \
-czf /var/backup/inc-2026-06-14.tar.gz /home
Код: Выделить всё
dd if=/dev/sda of=/mnt/img/sda.img bs=4M status=progress conv=fsync
# восстановление: dd if=sda.img of=/dev/sda bs=4M
Код: Выделить всё
dump -0u -f /backup/root.dump /dev/sda1 # уровень 0 = full
dump -1u -f /backup/root.lvl1 /dev/sda1 # инкремент относительно уровня 0
restore -rf /backup/root.dump # восстановление в текущий каталог
Код: Выделить всё
mt -f /dev/nst0 status # состояние ленты
mt -f /dev/nst0 rewind # перемотать в начало
mt -f /dev/nst0 fsf 2 # промотать через 2 файла-маркера
tar -cf /dev/nst0 /home # писать архив прямо на ленту
Код: Выделить всё
# Debian 13 / Ubuntu 24.04
apt install rsync dump mt-st
# RHEL 10 / Fedora 41+
dnf install rsync dump mt-st
- Слэш в rsync: rsync -a /home /backup кладет внутрь /backup/home, а rsync -a /home/ /backup льет содержимое прямо в /backup. Перепутали - получили лишний или недостающий уровень каталога.
- --delete без --dry-run на боевом приемнике: одна опечатка в пути источника превращает зеркало в пустую папку. Сначала всегда -n (dry-run).
- Бэкап смонтированной БД "как файлы" дает неконсистентную копию. Для MySQL/PostgreSQL делайте дамп (mysqldump/pg_dump) или снапшот на уровне LVM/ФС, а не копирование живых файлов.
- Обрыв цепочки инкрементов: потеряли один incremental в середине - все последующие бесполезны. Дифференциальный устойчивее, но толще.
- dd if/of перепутаны местами - и вы записали пустой образ поверх живого диска. Проверяйте направление трижды.
- Хранение единственной копии рядом с оригиналом (на том же сервере, в том же ЦОДе) - это нарушение 3-2-1, шифровальщик заберет и оригинал, и бэкап.
- "Зеленый лог = успех" - неверно. Без тестового restore вы не знаете, читается ли архив и полон ли он.
- Создайте каталог /srv/data с парой файлов и сделайте полный архив через tar --listed-incremental в /backup.
- Измените один файл, добавьте новый, запустите tar с тем же .snar - убедитесь, что инкремент маленький.
- Настройте снапшот-бэкап rsync с --link-dest на вчерашний каталог; через du -sh сравните реальный и кажущийся размер.
- Удалите часть данных в /srv/data и восстановите их из tar-цепочки (full, потом инкремент).
- Сделайте dd-образ небольшого loop-устройства и разверните его обратно, проверив контрольной суммой sha256sum.
- Опишите для своего стенда схему 3-2-1: где 3 копии, какие 2 носителя, что является offsite.
- Чем дифференциальный бэкап отличается от инкрементального по объему и по числу файлов, нужных для восстановления?
- Что произойдет при восстановлении, если в цепочке инкрементов потерян один промежуточный архив?
- Зачем в rsync используется --link-dest и за счет чего экономится место?
- Как влияет завершающий слэш в пути источника rsync на результат?
- Сформулируйте правило 3-2-1 и объясните, от каких угроз защищает именно offsite-копия.
- Почему устройство /dev/nst0 предпочтительнее /dev/st0 при записи нескольких архивов на одну ленту?
