Краткий ответ: Создайте отдельного пользователя на Storage VPS, установите свой SSH-ключ и запускайте rsync с продакшн-сервера по расписанию cron. Минимальная рабочая настройка занимает около десяти минут и даёт автоматические инкрементальные удалённые бэкапы каждую ночь.
Обзор
Это канонический паттерн бэкапов Cloud2Y: продакшн отправляет данные через SSH на Storage VPS в другой локации. rsync передаёт только изменённые файлы, поэтому ночные запуски быстрые и экономные к каналу; раскладка с датированными снапшотами добавляет сверху восстановление на момент времени.
Что нужно иметь
- Storage VPS (как заказать) и root/SSH-доступ к продакшн-серверу, который бэкапите.
- Достаточно свободного места на цели как минимум для первой полной копии (см. оценку размера).
- Пару SSH-ключей для автоматизации — запросы пароля и cron несовместимы.
Пошаговая инструкция
- На Storage VPS подготовьте пользователя и целевой каталог:
adduser backupuser mkdir -p /srv/backups/web1 && chown -R backupuser:backupuser /srv/backups - На продакшн-сервере создайте ключ и установите его:
ssh-keygen -t ed25519 -f ~/.ssh/backup_key -N "" ssh-copy-id -i ~/.ssh/backup_key.pub [email protected] - Проверьте ручную синхронизацию каталогов с данными:
rsync -avz -e "ssh -i ~/.ssh/backup_key" /var/www/ [email protected]:/srv/backups/web1/www/ - Сначала дампите базы данных, чтобы бэкапы были консистентны:
mysqldump --all-databases | gzip > /var/backups/db.sql.gz - Соберите оба шага в скрипт и запланируйте через cron, напр. ежедневно в 03:30:
30 3 * * * /usr/local/bin/backup-to-storage.sh >> /var/log/backup.log 2>&1 - Проверьте следующим утром: файлы на Storage VPS на месте, в логе нет ошибок, размеры выглядят правильно.
Типичные проблемы
- Cron-задача тихо падает: используйте абсолютные пути в скрипте и логируйте вывод, как показано выше — см. автоматизацию бэкапов через cron.
- Бэкапы без баз данных: копировать живые файлы БД ненадёжно; всегда делайте дамп, а потом синхронизируйте его.
- Нет истории: обычное зеркало перезаписывает вчерашнее состояние — добавьте датированные каталоги или используйте restic/borg для настоящих снапшотов (см. хранение).
Когда обращаться в поддержку
Cloud2Y отвечает за платформу, а ваши бэкап-задачи — за вами; но если сам Storage VPS ведёт себя странно (ошибки диска, обрывы сети во время передач), откройте тикет с временными метками и логами.
Частые вопросы
Сколько длится первый бэкап?
Первый запуск копирует всё, поэтому время зависит от объёма данных и канала; следующие запуски rsync передают только изменённые файлы и обычно завершаются за малую долю этого времени.
Зачем дампить базы данных вместо копирования файлов?
Живые файлы БД меняются во время копирования и часто восстанавливаются повреждёнными. mysqldump или pg_dump даёт консистентный снимок, который надёжно импортируется на любом совместимом сервере.
Как знать, что ночной бэкап действительно выполнился?
Логируйте каждый запуск в файл и проверяйте строку успеха — например, финальную запись "backup OK" с временной меткой. Если строки нет, задача упала или не стартовала — разбирайтесь.
Похожие статьи
- Как делать бэкап Linux-сервера с помощью rsync
- Как автоматизировать бэкапы через cron
- Политика хранения бэкапов: объяснение
- Как проверить целостность бэкапов
Готовы начать? Заказать Storage VPS в Cloud2Y →
