Коротка відповідь: Створіть окремого користувача на 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 →
