Потеря данных может обернуться катастрофой для любого бизнеса. Чтобы не полагаться на удачу, стоит автоматизировать резервное копирование.
В этом материале рассказали, как настроить автоматическое резервное копирование на белорусском VPS с помощью связки rsync + cron. Разобрали установку и настройку rsync, создание задачи в cron, проверку работоспособности и дополнительные меры.
Установка rsync на сервере
Для начала проверьте, установлен ли на вашем VPS rsync. На большинстве Linux-дистрибутивов он есть по умолчанию. Проще всего проверить, набрав в терминале команду для просмотра версии:
rsync –version
Если система ответила номером версии, значит утилита уже готова к работе. В противном случае нужно установить rsync самостоятельно. Команда установки зависит от вашей операционной системы.
Debian/Ubuntu:
sudo apt update && sudo apt install rsync -y
CentOS/RHEL (Yum):
sudo yum install rsync -y
Если в системе используется пакетный менеджер dnf, команда аналогична: sudo dnf install rsync -y.
Как видите, установка предельно проста и сводится к одной команде пакетного менеджера. После инсталляции снова выполните rsync –version, чтобы проверить, добавлена ли утилита в систему.
Базовая настройка rsync и первый бекап
Теперь, когда rsync установлен, можно настроить первое резервное копирование вручную, это поможет отладить процесс, прежде чем пускать всё на автопилот. Предположим, вы хотите скопировать содержимое какого-то каталога, например, с веб-сайтом или базой данных, в папку для бекапов. Для этого достаточно одной команды:
rsync -av /путь/к/исходным/данным /путь/к/папке/для/бекапа
В этом примере rsync синхронизирует все файлы из директории с данными в целевой каталог. Ключ -a, архивный режим, сохраняет права доступа, временные метки и структуру каталогов, то есть, копирует всё как есть. Ключ -v включает подробный вывод в консоли, чтобы вы видели список скопированных файлов.
Совет: заранее создайте папку, куда будут складываться резервные копии. На этом разделе диска должно быть достаточно свободного места для ваших данных.
Rsync прекрасно работает не только в пределах одного сервера, но и по сети. Если нужно отправлять копию на другой сервер, например, на удалённое хранилище или второй VPS, команда будет чуть длиннее:
rsync -avz -e “ssh -p 22” /путь/к/исходным/данным
[USER]@[REMOTE_HOST]:/путь/к/папке/для/бекапа
Здесь вы добавили параметр -z для сжатия данных во время передачи, это ускоряет копирование по Интернету. Опция -e “ssh -p 22” указывает использовать SSH-протокол, порт 22 по умолчанию; если удалённый SSH работает на другом порте, впишите его. Вместо [USER]@[REMOTE_HOST]:/путь/к/папке нужно подставить логин и адрес вашего резервного сервера и путь до каталога, куда складывать файлы. После выполнения этой команды rsync подключится к удалённой машине по SSH и скопирует туда данные. Разумеется, на удалённом сервере тоже должен быть установлен rsync.
Часто бывает необходимо исключить из бекапа лишние файлы, например, временные логи или кеш. Для этого у rsync есть параметр –exclude. Вы можете перечислить маски или каталоги, которые не нужно копировать. Например:
rsync -av –exclude=”*.tmp” /путь/к/данным /путь/к/папке/для/бекапа
Такой запуск пропустит все файлы с расширением .tmp. Исключать можно по шаблону имени или указав конкретный каталог; флаг –exclude допускается указывать несколько раз для разных шаблонов.
Ещё один полезный флаг — –delete. Он отвечает за синхронизирование удаления. Если вы убрали какой-то файл в исходной директории, то при следующем запуске rsync удалит этот файл и в папке бекапа. Это помогает поддерживать резервную копию актуальной и очищенной от старого хлама. Но будьте осторожны, –delete бездумно удалит на стороне бекапа всё, чего нет в оригинале, поэтому убедитесь, что указали верные пути. Для начала можете не включать –delete, а добавить его позже, когда убедитесь, что всё работает корректно.
Настройка cron для автоматического бекапа
После того как вы отладили резервное копирование вручную, можно поручить эту задачу расписанию. Cron — стандартный планировщик задач в Linux, позволяющий выполнять команды по таймеру. Мы настроим cron так, чтобы он запускал вашу команду rsync автоматически, например, каждый день ночью.
Сначала откройте файл расписания cron. Достаточно выполнить в терминале команду:
crontab -e
Если вы запускаете эту команду впервые, система может спросить, какой текстовый редактор использовать. Выберите любой, с которым вам удобно. Откроется файл crontab для текущего пользователя. Если вы вошли под root, то редактируется cron для администратора, как раз то, что нужно, ведь бекап системных данных требует прав root.
Теперь добавьте задачу. Допустим, вы хотите запускать резервное копирование каждый день в 2:00 ночи. В конце файла crontab впишите строку:
0 2 * * * rsync -avz –delete /путь/к/исходным/данным /путь/к/папке/для/бекапа >>
/var/log/rsync.log 2>&1
Пять первых символов 0 2 * * * — это расписание задачи. Формат cron включает пять полей: минуту, час, день месяца, месяц и день недели. Звёздочки означают каждый соответствующий период. Таким образом, 0 2 * * * — это каждый день в 2 часа 0 минут, то есть, ежедневно в 02:00 ночи. Вы можете настроить другой график, например, 0 3 * * 0 запустит команду раз в неделю по воскресеньям в 3:00, а 30 23 * * * — каждый день в 23:30.
Далее идёт сама команда rsync с теми же ключами, что вы использовали вручную. Вы также добавили в конец строки конструкцию >> /var/log/rsync.log 2>&1. Она перенаправляет весь вывод команды rsync в файл лога /var/log/rsync.log. То есть, каждый ночной запуск будет дописывать информацию о скопированных файлах или возможных ошибках в этот файл. Так вы всегда сможете просмотреть лог и убедиться, что копирование действительно произошло.
Сохраните и закройте crontab. Изменения вступят в силу мгновенно, cron уже знает о новой задаче. Чтобы убедиться, что запись добавилась, выполните команду crontab -l. Она выведет весь список cron-задач для текущего пользователя. В этом списке вы должны увидеть только что добавленную строку расписания.
Если требуется резервное копирование не на локальный диск, а сразу на другой сервер, команда в crontab будет похожей, только с указанием удалённого хоста. Например, чтобы копировать на удалённый сервер по SSH в 3:00 ночи, можно добавить отдельную строку:
0 3 * * * rsync -avz -e “ssh -p 22” /путь/к/данным [USER]@[REMOTE_HOST]:/путь/к/папке/для/бекапа >> /var/log/rsync.log 2>&1
Так можно настроить несколько разных задач cron для разных целей, например, ежедневный локальный бекап на том же сервере и еженедельный на удалённое хранилище.
Автоматизация настроена, теперь сервер сам будет выполнять резервное копирование по заданному графику.
Проверка работы бекапа
После настройки cron не забудьте проконтролировать, что резервное копирование действительно выполняется по расписанию. Не просто же так вы всё настраивали! Есть несколько способов убедиться в работоспособности автобекапа:
- Подождать и проверить содержимое. Самый простой путь — дождаться следующего запланированного времени, скажем, до ночи, и наутро заглянуть в папку бекапа. Если там появились свежие файлы, всё в порядке. Можно создать пробный файл в исходной директории и убедиться, что после ночного запуска он появился в резервной копии.
- Принудительно запустить задачу. Не хочется ждать? Тогда запустите вашу команду вручную ещё раз и посмотрите на результат. Фактически, это симуляция работы cron. Например, выполните ту же строку rsync, что вы добавили в crontab без расписания в начале. Команда должна отработать без ошибок. Если всё хорошо, можете удалить созданный тестовый файл и дождаться следующего автоматического запуска.
- Просмотреть лог-файл. Вы настроили вывод rsync в файл /var/log/rsync.log. Откройте его после предполагаемого времени бекапа. В файле должен быть список скопированных объектов или сообщение типа Nothing to copy, если с момента прошлого раза ничего не изменилось. Если в логе есть ошибки, нужно разобраться и исправить их.
- Проверить системный журнал cron. cron пишет информацию о запуске задач в системный лог. В Ubuntu/Debian эти записи можно найти в файле /var/log/syslog. Выполните команду фильтрации:
cat /var/log/syslog | grep rsync
Вы увидите строки, которые cron добавляет при каждом запуске вашей задачи. Если таких записей нет, значит cron почему-то не выполняет команду, возможно, допущена ошибка в расписании или синтаксисе crontab. В CentOS и других системах журнал может находиться в другом месте, например, в /var/log/cron.
- Email-уведомление об ошибке. Cron по умолчанию может отправлять владельцу задачи письмо, если та завершилась с ошибкой или выдала какой-то вывод. Чтобы получать такие письма на свою почту, можно вверху файла crontab прописать специальную переменную окружения:
MAILTO=”you@example.com”
Теперь при сбое или любой выдаче текста в stdout/stderr вы получите сообщение на указанный адрес. Учтите, что для этого на сервере должен быть настроен локальный почтовый сервер. Если такой возможности нет, ограничьтесь просмотром логов вручную.
После проверки вы обретёте уверенность, что резервное копирование действительно работает без вашего участия. Но расслабляться рано, впереди ещё пара важных штрихов.
Безопасность и хранение бекапов
Вы автоматизировали процесс резервного копирования, теперь важно позаботиться о хранении самих копий и безопасности процедуры.
Настройте доступ по ключам SSH. Если вы копируете данные на удалённый сервер, настоятельно рекомендуется использовать SSH-ключи вместо паролей. Это не только удобно, но и безопасно. Сгенерируйте ключ командой ssh-keygen на основном сервере и добавьте публичный ключ на резервный сервер с помощью ssh-copy-id [USER]@[REMOTE_HOST]. Теперь rsync по SSH будет проходить автоматически, и вы можете даже отключить парольную аутентификацию для пользователя бекапа на удалённой машине.
Ограничьте права доступа к резервным копиям. Каталог с бекапами должен быть защищён от постороннего доступа. Проще всего задать права так, чтобы только root или специальный пользователь-бекапер могли читать и менять эти файлы. Например, можно рекурсивно ограничить доступ командой:
chmod -R 700 /backup
Это запретит всем остальным пользователям лазить в вашу папку с копиями. Помните, что сами бекапы порой содержат критичные данные, поэтому их утечка не менее опасна, чем потеря.
Храните копии вне основного сервера. Бекап, который лежит на том же физическом сервере, не спасёт от проблем с железом или форс-мажоров вроде пожара в дата-центре. Идеальный вариант — отправлять резервные копии на другую площадку. Арендуйте отдельный сервер-хранилище либо пользуйтесь облачным сервисом. Так данные переживут даже полное уничтожение основного VPS. Показательный случай: владелец одной хостинг-компании по ошибке выполнил на своих серверах команду, которая удалила всё, и рабочие данные, и бекапы, потому что копии хранились на тех же машинах. Бизнес пришлось закрыть. Урок прост: не кладите все яйца в одну корзину.
Делайте несколько версий бекапа. Если постоянно перезаписывать одну-единственную резервную копию, вы не застрахованы от неприятностей. Представьте: сбой повредил данные, вы этого не заметили, и при следующем запуске rsync благополучно скопировал испорченные файлы, переписав ими хорошую копию. Чтобы избежать подобного, полезно хранить историю, хотя бы несколько предыдущих состояний данных. Проще говоря, организуйте ротацию бекапов. Например, можно сохранять ежедневные резервные архивы за последние 7 дней, а раз в неделю откладывать отдельный архив на долгий срок. Утилита rsync способна помогать с версионированием. Ключ –backup вместе с –backup-dir позволяет при каждом запуске сохранять старые версии изменённых файлов в отдельной папке. То есть, в основной директории у вас всегда актуальные данные, а всё, что изменилось или удалилось, переезжает в каталог наподобие /backup/old с отметкой даты. При необходимости можно найти там прежнюю версию файла и восстановить её. Недаром системные администраторы шутят: «Если у вас только один бекап — у вас нет бекапа». Обязательно держите хотя бы две резервные копии и регулярно проверяйте их работоспособность и соответствие друг другу.
Заключение
Настройка автоматического бекапа на VPS — это небольшое усилие сегодня, которое может спасти от огромных проблем завтра. Теперь ваши данные под надёжной защитой: если вдруг что-то пойдёт не так, вы не потеряете все результаты своего труда. Конечно, не стоит совсем забывать про резервные копии, важно время от времени проверять, что они корректно восстанавливаются, и при необходимости обновлять стратегию резервирования по мере роста проекта. Зато сам факт, что копирование происходит автоматически, снимает с ваших плеч значительную часть рисков и рутинных забот. Вы можете выдохнуть и направить силы на развитие своих идей, не опасаясь, что внезапный сбой уничтожит всё разом. Вы позаботились о резервной копии, а значит, даже в самый неожиданный момент ваши данные останутся в сохранности и ваш проект продолжит работу.