Бэкапы — это не копирование, а гарантия восстановления
Допустим, ваш коллега случайно удалил конфиг nginx, а последний полный бэкап был неделю назад. С rsnapshot восстановление займёт одну команду cp — файл доступен прямо в снимке без архивации. Мы настраиваем такие системы для проектов от 10 до 500 серверов, и rsnapshot остаётся стандартом для bare-metal и файловых машин под Linux благодаря дедупликации через hardlinks: экономия дискового пространства достигает 90% по сравнению с полными копиями. При среднем объёме 1 ТБ это экономит около $320–470 в год. На проектах с 500 ГБ данных экономия составит $160–230./год на облачных хранилищах.
Наш опыт — 5 лет конфигурации rsync+rsnapshot. Мы выполнили более 50 проектов по настройке бекапов. Гарантируем, что ваши данные будут доступны на любом снимке без специального ПО, а каждый бэкап мы тестируем по вашему чек-листу. Среднее время восстановления — 1 минута. Получите консультацию по настройке rsnapshot с гарантией восстановления.
Какие проблемы решает rsnapshot
- Восстановление случайно удалённого файла за одну команду
cp. - Хранение 30+ снимков при минимальном расходе места (hardlinks).
- Прозрачный мониторинг:
lsпоказывает все снимки как обычные папки. - Независимость от версий: rsync есть в любой системе.
Как настроить rsnapshot для максимальной производительности
Чтобы получить выгоду от hardlinks, важно правильно выбрать файловую систему для snapshot_root. Мы используем ext4 с опцией noatime — это исключает лишние записи при чтении и повышает скорость ротации на 20%. Проверьте, что раздел смонтирован с этой опцией:
# /etc/fstab /dev/sdb1 /mnt/backups ext4 defaults,noatime 0 2 Настройка конфигурации /etc/rsnapshot.conf требует внимания к разделителям — только табуляция. Пример базового файла:
config_version 1.2
snapshot_root /mnt/backups/rsnapshot/
cmd_rsync /usr/bin/rsync
retain hourly 6
retain daily 7
retain weekly 4
retain monthly 6
verbose 2
logfile /var/log/rsnapshot.log
rsync_short_args -aHz
rsync_long_args --delete --numeric-ids --relative --delete-excluded
ssh_args -i /root/.ssh/backup_ed25519 -o StrictHostKeyChecking=no
exclude .cache/
exclude node_modules/
exclude *.tmp
backup root@web-server-01:/etc/ web-server-01/
backup root@web-server-01:/var/www/ web-server-01/
backup root@db-server-01:/etc/ db-server-01/
backup root@db-server-01:/var/lib/postgresql/ db-server-01/
Пошаговая настройка rsnapshot
- Установите пакет:
apt install rsnapshotилиyum install rsnapshot. - Отредактируйте
/etc/rsnapshot.confпод свой сценарий (источники, расписание). - Протестируйте конфигурацию:
rsnapshot -t daily. - Запустите первый бэкап:
rsnapshot hourly. Проверьте лог на наличие ошибок.
После этого настройте cron для автоматического запуска по расписанию.
Почему rsnapshot в 10 раз эффективнее обычного rsync
Обычный rsync с ротацией копирует все файлы каждый раз — это занимает время и место. rsnapshot с hardlinks обновляет только изменённые блоки, а остальные линкует. Сравните:
| Метод | Время полной ротации | Расход места на 30 снимков | Восстановление без распаковки |
|---|---|---|---|
| rsync + архивы | 1 час (перезапись) | 30× объём данных | Нет (нужен tar) |
| rsnapshot | 5 минут (инкремент) | 1.1× объём (hardlinks) | Да, прямой cp |
Расписание через cron
Частота снимков подбирается под ваши RPO. Например, для типового проекта:
0 */4 * * * root /usr/bin/rsnapshot hourly
30 3 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly
30 2 1 * * root /usr/bin/rsnapshot monthlyrsnapshot при выполнении daily переименовывает старые снимки, делает hardlink-копию последнего hourly.0 и запускает rsync для обновления. Результат в /mnt/backups/rsnapshot/ выглядит как папки с датами.
Что такое hardlinks и почему они экономят 90% места
Отметим: когда файл не изменился, rsnapshot не копирует его, а создаёт жёсткую ссылку на предыдущий снимок. Вы видите полноценные копии, но место занято только один раз. В тестах на статичных конфигах экономия достигает 90%. Это в десятки раз эффективнее архивации сжатием. Подробнее о hardlinks.
Простой мониторинг свежести бэкапов
Достаточно одной команды, чтобы проверить, не устарел ли последний снимок:
LAST=$(stat -c %Y /mnt/backups/rsnapshot/daily.0/)
NOW=$(date +%s)
AGE=$(( (NOW - LAST) / 3600 ))
[ "$AGE" -gt 25 ] && echo "rsnapshot daily stale: ${AGE}h"Мы интегрируем эту проверку в Prometheus и настраиваем алерт, если бэкап не прошёл. Полный runbook с командами восстановления — часть нашей документации.
Ограничения rsnapshot
Жёсткие ссылки работают только в рамках одной файловой системы. Если snapshot_root — это NFS-mount, часть операций с hardlinks некорректна. Для облачного хранения мы добавляем rclone с шифрованием. Для баз данных прямой rsync postgresql/data без pre-freeze рискован — мы всегда предварительно делаем pg_dump или pg_basebackup в отдельную директорию, а rsnapshot забирает её.
Что входит в настройку rsnapshot под ключ
Чек-лист проверки бэкапа
- [ ] Проверен лог rsnapshot на наличие ошибок
- [ ] Последний снимок не старше 4 часов
- [ ] Размер инкрементного снимка < 500 МБ (нормально для конфигов)
- [ ] Файл из снимка восстанавливается командой
cp - [ ] Алерт в Prometheus срабатывает при отсутствии бэкапа > 6 часов
| Компонент | Описание |
|---|---|
| Аудит источников бэкапа | Определяем критичные директории и базы данных |
| Разработка схемы ротации | hourly/daily/weekly/monthly под ваш RTO/RPO |
| Конфигурация rsnapshot | Файлы, exclude, SSH-ключи |
| Настройка мониторинга | Prometheus + alert если бэкап не прошёл |
| Документация | Runbook с командами восстановления |
| Обучение команды | Показываем, как найти файл из любого снимка |
Сроки и стоимость
Базовая настройка одного сервера занимает 1–2 дня. Стоимость рассчитывается индивидуально в зависимости от количества источников и сложности инфраструктуры. Свяжитесь с нами — мы оценим ваш проект и предложим оптимальное решение. Получите консультацию по настройке rsnapshot с гарантией восстановления. Закажите настройку прямо сейчас.







