Перейти к содержимому 
Я автоматизирую свой резервное копирование rsyncчтобы избежать сбоев и сделать восстановление предсказуемым. Благодаря четкому Задания CronSSH-транспортировка и инкрементные прогоны позволяют мне эффективно защищать веб-серверы, базы данных и конфигурации.
Центральные пункты
- АвтоматизацияКонтролируемые по времени задания сокращают количество ошибок и усилий.
- ЭффективностьДельта-передача экономит полосу пропускания и память.
- БезопасностьSSH, управление ключами и удаленные цели.
- СтратегияСохранение GFS и четкие цели RPO/RTO.
- ПрозрачностьВедение журнала, мониторинг и тесты восстановления.
Почему я автоматизирую резервное копирование
Я последовательно защищаю продуктивные системы, потому что один сбой может привести к остановке всего проекта, и я Наличие хочет гарантировать. Резервное копирование по расписанию в 02:00 заменяет подверженную ошибкам ручную работу и обеспечивает чистоту состояния данных. Я определяю четкие цели для каждого сервера: Насколько допустима потеря данных (RPO) и как быстро должно происходить восстановление (RTO). Эти цели влияют на расписание, цели хранения и опции, чтобы обеспечить надежную защиту операций. В частности, для веб-серверов я снижаю риски, связанные с дефектами оборудования, вымогательством или случайным удалением, до расчетного минимума.
Краткое описание rsync: функциональные возможности и достоинства
rsync передает только изменения, использует эффективный Трансфер Дельта и избегает ненужных копий. Это значительно сокращает время выполнения, нагрузку на сеть и IO на целевой системе. Я работаю в режиме архива (-a), чтобы права доступа, время, владельцы и симлинки оставались неизменными. Я поддерживаю зеркала в актуальном состоянии с помощью -delete, но обращаю внимание на целевое использование и сочетаю его с отдельными каталогами для версионности. Я использую SSH для транспортировки, прямые пути для локальных заданий и добавляю сжатие (-z) и ограничение пропускной способности (-bwlimit), если это необходимо.
Автоматизация с помощью Cron: шаг за шагом
Я начинаю с простого сценария, потому что ясный Базовые линии может быть расширена позже. Сначала я устанавливаю rsync, если он отсутствует, и создаю безопасный рабочий каталог для журналов и состояния. Затем я пишу сценарий с источниками, целью и разумными параметрами, включая исключения. Сценарий запускается ежедневно или ежечасно в зависимости от RPO и пишет файлы журналов для оценки и оповещения. Пробный запуск (-n) перед первым продуктивным запуском предотвращает нежелательные удаления.
Установка # (Debian/Ubuntu)
sudo apt-get install rsync
# Минимальный запуск локально
rsync -a /data/www/ /backup/www/
# Удаленное зеркало через SSH с возможностью удаления
rsync -a --delete -e "ssh -i /root/.ssh/backup_key" /data/www/ backup@backuphost:/srv/backups/www/
# Cron: ежедневно в 02:00 утра.
0 2 * * * * /usr/local/bin/rsync-backup.sh >> /var/log/rsync-backup.log 2>&1
Безопасная настройка резервного копирования по SSH
Я использую ключи SSH с ограниченными правами, потому что Управление ключами уменьшает поверхность атаки. На целевой системе я ограничиваю команды с помощью authorised_keys и использую отдельного резервного пользователя. Fail2ban, правила брандмауэра и ограничительные опции SSH (например, PasswordAuthentication no) повышают безопасность. Я храню ключ хоста, чтобы у "человека посередине" не было шансов. Если вы ищете структурированное начало, вы можете найти проверенные и испытанные идеи на сайте Автоматизируйте резервное копирование.
Тянуть, а не толкать: преимущества безопасности на практике
По возможности я оставляю Резервное копирование сервера вместо того, чтобы перебрасывать на рабочий сервер. В результате производственные системы остаются без исходящих ключей, а взломанный веб-сервер не может удалить резервные копии, находящиеся за пределами предприятия. На целевом сервере я ограничиваю ключ в authorised_keys с помощью ограничительных параметров и принудительной команды.
# Пример авторизованных_ключей на резервной цели
from="10.0.0.10",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding,command="/usr/local/bin/rsync-serve-backups"
/home/backup/.ssh/authorised_keys
Вызываемый скрипт разрешает только вызовы сервера rsync и устанавливает ограничения на пути. Вот как я добиваюсь Принцип минимальных правбез усложнения эксплуатации.
Версионирование и хранение с помощью жестких ссылок
Для нескольких стендов я создаю ежедневные, еженедельные и ежемесячные папки с -link-dest, потому что Hardlinks Экономия памяти и упрощение восстановления. Каждое поколение относится к идентичным, неизменным файлам из предыдущей резервной копии; новые или измененные файлы физически оказываются в новой папке. Это позволяет мне создавать множество точек восстановления при умеренных требованиях к объему памяти. Я удаляю старые поколения с помощью простого сценария ротации без риска для целостности данных. Фиксированное расписание (например, 7 дней, 4 недели, 6 месяцев) позволяет четко и прозрачно планировать хранение.
Контролируйте ресурсы: Пропускная способность, процессор и ввод/вывод
Я ограничиваю пропускную способность данных с помощью параметра -bwlimit, чтобы Производительная нагрузка остается стабильным, и пользователи не несут никаких потерь. Я использую nice и ionice для определения приоритетов процессов резервного копирования. Я включаю сжатие (-z) в медленных сетях и оставляю его выключенным на быстрых локальных носителях. Для больших файлов я выбираю -partial, чтобы иметь возможность продолжать отмененные передачи. Для локальных зеркал я часто использую -whole-file, потому что алгоритм дельты не имеет преимуществ.
Согласованные состояния данных: моментальные снимки и базы данных
Чтобы поддерживать последовательное резервное копирование, несмотря на открытые файлы, я использую Снимки или крючки приложений. Файловые системы, такие как LVM, ZFS или Btrfs, позволяют делать быстрые снимки, которые я использую в качестве источника для rsync. Это позволяет мне логически заморозить состояние данных, не блокируя сервисы на длительное время.
# Пример: снимок LVM в качестве согласованного источника
lvcreate -L 10G -s -n data_snap /dev/vg0/data
смонтируйте /dev/vg0/data_snap /mnt/data_snap
rsync -a --delete /mnt/data_snap/www/ backup@host:/srv/backups/www/
umount /mnt/data_snap
lvremove -f /dev/vg0/data_snap
Для Базы данных Я разделяю логику и файлы. Резервное копирование MySQL/MariaDB я делаю с помощью дампа или решений Percona/Xtra, PostgreSQL - с помощью pg_dump или basebackups. Важна последовательность: сначала создайте последовательный дамп, затем передайте путь к дампу через rsync. Это предотвратит появление полузаписанных файлов в резервной копии.
Типичные источники ошибок и как их избежать
Самым распространенным камнем преткновения является косая черта в конце пути, поэтому я проверяю Детали пути двойное: /src/ против /src. Я тестирую исключения с помощью -dry-run и -itemise-changes, чтобы увидеть эффект. Я правильно цитирую шаблоны с пробелами и сохраняю файл исключений в репозитории. Перед командой -delete я проверяю монтирование, поскольку немонтированная цель может привести к нежелательному удалению. Наконец, я регистрирую коды возврата и активирую сигналы тревоги, чтобы сразу видеть ошибки.
Стратегия резервного копирования: GFS и цели восстановления
Сначала я устанавливаю RPO/RTO, потому что ясно Цели Руководствуйтесь каждым решением о частоте, месте хранения и сроках хранения. Обычная схема - GFS: ежедневные дифференциальные, еженедельные полные или объединенные по жестким ссылкам, ежемесячные долгосрочные. На срок хранения влияют требования по соблюдению нормативных требований, поэтому я отделяю недолговечные оперативные данные от долгосрочных архивов. Для критически важных систем я планирую резервное копирование вне офиса в дополнение к локальным копиям. Такая комбинация защищает от сбоев в работе сайта и позволяет быстро и удаленно восстанавливать данные.
Cron или systemd-timer: надежное планирование
Cron прост и надежен. Для хостов, которые периодически спят или перезагружаются, я также использую systemd-timer с зависимостями и обработкой пропущенных запусков. Это гарантирует, что после перезагрузки ни один запуск не завершится неудачей и что последовательность будет правильной (например, после восстановления сети).
# /etc/systemd/system/rsync-backup.service
[Unit]
Описание=Rsync Backup
После=network-online.target
Хочет=network-online.target
[Сервис]
Тип=oneshot
ExecStart=/usr/local/bin/rsync-backup.sh
Хороший=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7
# /etc/systemd/system/rsync-backup.timer
[Unit]
Описание=Ежедневный таймер резервного копирования Rsync
[Timer]
OnCalendar=02:00
Persistent=true
[Install]
WantedBy=timers.target
Таблица: Важные опции rsync в повседневной жизни
Я использую несколько, но эффективных Опциикоторые я документирую для каждой работы и версии в репозитории. Режим архивации составляет основу и уменьшает количество ошибок при настройке. Я поддерживаю чистоту зеркал с помощью -delete, но использую его только при правильной проверке цели. Для версионирования я комбинирую -link-dest с планом ротации. В следующей таблице приведены наиболее важные переключатели и их использование.
| Вариант | Назначение | Подсказка |
|---|---|---|
| -a | Режим архивации | Принимает на себя права, время, право собственности на Последовательность |
| -z | Компрессия | Полезно для WAN, в локальной сети часто не используется |
| -удалить | Удаляет удаленные унаследованные файлы | Используйте только зеркала, предварительно проверив их на практике. |
| -bwlimit=KBPS | Пропускная способность дроссельной заслонки | Защищает Продуктивные системы от пиков нагрузки |
| -link-dest=DIR | Версионирование с помощью жестких ссылок | Экономичные поколения с отдельными папками |
| -e "ssh ..." | Безопасная транспортировка | Ключи, хост-ключи, пользователи с ограничениями |
| -n / -dry-run | Тестовый запуск без изменений | Показывает заранее запланированные действия |
Восстановление после испытаний: Восстановительные упражнения
Я регулярно проверяю восстановление, потому что резервное копирование без восстановления - это только Внешний вид это. Для образцов я восстанавливаю отдельные файлы и целые веб-сервисы в средах для тестирования. Я создаю резервные копии баз данных по отдельности с помощью дампов и импортирую их на тестовой основе для проверки целостности. Контрольные суммы помогают мне подтвердить целостность и распознать тихие битовые ошибки. После каждого теста я адаптирую документацию, скрипты и плейбуки, чтобы следующая аварийная ситуация выполнялась быстрее.
Резервное копирование "чистого металла" и системы: особенности
Для резервного копирования системы или пустого металла я расширяю параметры rsync до ACL, xattrs и жесткие ссылки чтобы взять с собой. В Linux хорошо зарекомендовали себя -aAXH и -numeric-ids. Я исключаю псевдофайловые системы, такие как /proc, /sys, /run, /dev/pts, и создаю резервные копии загрузочных и конфигурационных файлов отдельно.
# Резервное копирование, связанное с системой (пример)
rsync -aAXH --numeric-ids \
--exclude={"/proc/*","/sys/*","/run/*","/dev/pts/*","/tmp/*"} \
/ root@backup:/srv/backups/hostA/current/
Восстановление # (упрощенное, с живого носителя)
rsync -aAXH --numeric-ids /srv/backups/hostA/current/ /mnt/target/
chroot /mnt/target update-initramfs -u
grub-install /dev/sda && update-grub
Я планирую больше времени на такое восстановление, документирую последовательность действий и держу под рукой шаги по загрузчику. Это значительно снижает стресс в экстренных ситуациях.
Интеграция с Plesk: умное объединение рабочих мест в панели
Я объединяю задачи Plesk с rsync, чтобы Резервные копии панелей и внеофисные копии работают вместе. После резервного копирования крючки немедленно переносят свежие резервные копии на внешнее хранилище. Расписание совпадает с окнами обслуживания, поэтому развертывание и резервное копирование не мешают друг другу. Ротация журналов в панели и на целевой системе предотвращает рост каталогов журналов. Хорошей отправной точкой является Лучшие практики Plesk с упором на повторяющиеся процессы.
Интеграция с cPanel: домашние адреса и базы данных
Затем я передаю резервные копии cPanel на внешний хост через rsync, чтобы Защита от внешних воздействий остается без дополнительной нагрузки. Структура каталогов облегчает выборочное восстановление отдельных учетных записей. Для крупных реселлеров я планирую дифференциальное восстановление на ночь, а полное - на выходные. В сочетании с квотами и ротацией я поддерживаю прозрачность требований к хранению. Практичным дополнением являются заметки о Резервное копирование cPanel для обеспечения надежной повседневной работы.
Масштабирование и структура: чистое управление большим количеством заданий
Когда среда растет, я централизованно структурирую источники и исключения. С помощью -файлы с сайта Я переношу списки, которые я верстаю в репо. Таким образом, я меняю записи, не трогая скрипты, и сохраняю последовательность расположения.
Файлы # - из примера
/etc/backup/www.list
/data/www/
/etc/nginx/
/var/www/html/
rsync -a --delete --files-from=/etc/backup/www.list / backup@host:/srv/backups/www/
Я избегаю дублирования, четко разделяя ответственность за пути (например, Webroot отдельно от журналов). Для больших наборов я сознательно планирую параллелизм - лучше несколько хорошо отлаженных заданий, чем десятки конкурирующих процессов.
Надежность в работе: блокировка, повторные попытки, тайм-ауты
Чтобы избежать дублирования, я использую флоксы или файлы блокировки. Я перехватываю сетевые проблемы с помощью Retries и -partial. С помощью -timeout я чисто завершаю зависшие соединения и подаю сигнал тревоги.
# /usr/local/bin/rsync-backup.sh (отрывок)
#!/usr/bin/env bash
set -euo pipefail
exec 9> /var/lock/rsync-backup.lock
flock -n 9 || { echo "Backup already running"; exit 1; }
LOG=/var/log/rsync-backup.log
SRC=/data/www/
DST=backup@backuphost:/srv/backups/www/
for i in {1..3}; do
if rsync -a --delete --partial --timeout=600 -e "ssh -i /root/.ssh/backup_key" "$SRC" "$DST"; then
echo "OK"; exit 0
fi
echo "Повторная попытка $i" | tee -a "$LOG"
sleep 60
готово
echo "Ошибка после повторных попыток" >> "$LOG"; exit 1
Опции для особых случаев: ACL, xattrs, разреженность и атомарность
Я адаптирую rsync в зависимости от типа данных. Для веб и системных путей я создаю резервные копии ACL и xattrs с помощью -A -X. Большие, редко используемые файлы (образы ВМ, базы данных) получают преимущество от -sparse. С -delay-updates и -delete-delay Я минимизирую промежуточные состояния и добиваюсь квазиатомарных обновлений на целевой машине. Для чувствительных данных я избегаю -inplace, чтобы дефектные передачи не перезаписывали последнюю хорошую копию.
# Пример для обширных метаданных
rsync -aAXH --sparse --delete-delay --delay-updates SRC/ DST/
Если мне нужны абсолютно атомарные каталоги (например, для постановки), я синхронизирую их с временной целью и запустить затем используйте mv для перехода к живому каталогу.
Надежные ограничения на удаление и проверка правдоподобности
Чтобы предотвратить катастрофы, вызванные неправильной конфигурацией, я установил -max-delete чем Guardrail. Перед запуском я также проверяю монтирование, свободную память и иноды. Я записываю в журнал последнее успешное резервное копирование и предупреждаю об отклонениях (экстремальные показатели удаления или модификации).
# Защита от массового удаления
rsync -a --delete --max-delete=5000 SRC/ DST/
# Проверка правдоподобности (простая)
df -h /srv/backups
df -i /srv/backups
Вкратце: Вот как я действую
Сначала я определяю RPO/RTO, потому что четкое Приоритеты руководствуйтесь каждым техническим выбором. Затем я пишу простой сценарий, тестирую его с помощью команды -dry-run и регистрирую каждое выполнение. Используя ключи SSH, ограничения пропускной способности и версионность, я создаю эффективные и отслеживаемые резервные копии. Удаленные пункты назначения дополняют локальные копии, а регулярные упражнения по восстановлению подтверждают их пригодность. Таким образом, мое резервное копирование rsync остается надежным, быстрым и всегда готовым к использованию.
