Резервне копіювання виділеного сервера
Робоча схема виглядає так: щоденний інкремент файлів і дамп СУБД у зовнішнє сховище, тижнева повна копія та щомісячна перевірка відновлення на окремій машині. RAID резервним копіюванням не є: дзеркало чесно повторить помилкове видалення і роботу шифрувальника на обох дисках одночасно.
- Правило 3-2-1: три копії даних, два різні носії, одна копія за межами сервера.
- Копія, з якої жодного разу не відновлювалися, копією не вважається — перевірка раз на місяць обов'язкова.
- База копіюється дампом або знімком файлової системи, а не порядковим копіюванням каталогу даних на живій СУБД.
- Обліковий запис, яким пише сервер, не повинен мати права видаляти старі копії: інакше шифрувальник зітре і їх.
- Опція копіювання в зовнішнє сховище коштує $10 на місяць і закриває вимогу «копія поза майданчиком».
Що копіювати і як часто
| Дані | Частота | Метод | Зберігання |
|---|---|---|---|
| Бази даних | Щодня, активні — щогодини | Дамп плюс бінарний журнал | 14 добових, 8 тижневих |
| Файли проєкту та завантаження | Щодня | restic або borg, інкремент | 14 добових, 12 місячних |
| Конфігурація системи | Щодня | Каталог /etc цілком | 30 діб |
| Пошта і черги | Щодня | rsync із жорсткими посиланнями | 7 діб |
| Віртуальні машини | Раз на тиждень | Знімок або експорт образу | 4 копії |
| Логи і кеш | Не копіювати | Винятки у списку | — |
Кеш, тимчасові каталоги та вміст /var/log роздувають копію в рази і майже ніколи не потрібні під час відновлення. Виносьте їх у список винятків від першого дня.
Інструменти
Для файлів беріть restic або borg: обидва дають дедуплікацію, шифрування на боці клієнта та інкрементні знімки без повного перечитування даних. Для баз — штатні дампи. Для вивантаження у хмарне сховище знадобиться rclone, а вибір самого сховища розібрано в матеріалі порівняння S3-сумісних сховищ.
# restic: репозиторій у S3-сумісному сховищі
export RESTIC_REPOSITORY='s3:https://s3.example.net/backup-srv1'
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
# щоденний інкремент файлів і конфігурації
restic backup /etc /var/www /home --exclude-file=/root/backup.exclude
# дамп бази прямо в потік, без проміжного файлу на диску
mysqldump --single-transaction --quick --all-databases \
| restic backup --stdin --stdin-filename all-databases.sql
# ретеншн і очищення
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
# перевірка цілісності репозиторію з читанням частини даних
restic check --read-data-subset=5%
# список винятків пишемо heredoc, щоб не втратити шаблони
cat > /root/backup.exclude << 'EOF'
/var/www/*/cache
/var/www/*/var/tmp
/var/log/journal
*.tmp
EOF
# borg: архів зі стисненням і статистикою
borg create --stats --compression zstd,3 \
/mnt/backup::srv1-{now:%Y-%m-%d} /etc /var/www
# перевірка архівів і список вмісту
borg check --verify-data /mnt/backup
borg list /mnt/backup
# відновлення однієї бази з дампа
mysql shop < /root/restore/shop.sql
Куди складати копії
Копія на тому самому масиві рятує лише від помилки оператора: пожежа, крадіжка чи вихід з ладу контролера знищать і дані, і копію. Мінімально прийнятна схема — локальна копія для швидкого відкату плюс другий майданчик. Додатковий жорсткий диск на 1 ТБ за $15 на місяць зручний як локальний буфер, а опція копіювання в зовнішнє сховище за $10 на місяць закриває винесення за межі сервера.
Якщо на машині працює гіпервізор, схему копій зазвичай будують на рівні віртуальних машин — як це робиться, описано в матеріалі Proxmox Backup Server. Відмова окремого накопичувача при цьому лишається окремою процедурою і розібрана у статті заміна диска в RAID-масиві.
Перевірка відновлення
Визначте два числа і тримайте їх у документації: RPO — скільки даних ви готові втратити, RTO — за скільки зобов'язані піднятися. З них випливає частота копій і спосіб відновлення. Далі раз на місяць робіть вправу повністю:
# піднімаємо копію в окремий каталог, не чіпаючи бойові дані
restic restore latest --target /srv/restore-test --include /var/www
# звіряємо файли з бойовими, показуємо лише відмінності
diff -rq /var/www /srv/restore-test/var/www | head -n 20
# відновлюємо базу в окрему схему і рахуємо рядки
mysql -e 'CREATE DATABASE shop_test;'
mysql shop_test < /root/restore/shop.sql
mysql -N -e 'SELECT COUNT(*) FROM shop_test.orders;' 2>&1
Найчастіша причина втрати даних не відмова диска, а копія, до якої мав право на видалення скомпрометований сервер. Шифрувальник заходить за збереженим ключем, стирає знімки у сховищі й лишає тільки зашифровані файли. Закривається це режимом лише на додавання в облікового запису копіювання, окремим ключем доступу та другою копією, якої сервер узагалі не бачить. Друга типова помилка — завдання в cron, яке мовчки падає: якщо вивід іде в /dev/null, ви дізнаєтеся про зламане копіювання в день аварії. Перевірка: заведіть окремий моніторинг віку останньої копії та вважайте завдання зламаним, якщо свіжого знімка немає понад 26 годин.
Коротко
- RAID не є резервною копією: він захищає від відмови диска, а не від видалення і шифрування.
- Тримайте три копії на двох носіях, одну — за межами сервера.
- Файли копіюйте restic або borg інкрементно, бази — дампом із ретеншном.
- Обліковому запису копіювання не давайте прав на видалення старих знімків.
- Раз на місяць відновлюйте копію та звіряйте кількість рядків і файлів.
Готові конфігурації з місцем під локальний буфер копій і з опцією зовнішнього сховища зібрані в розділі виділені сервери.