Коротка відповідь: Зберіть бекап-команди в скрипт, зробіть його виконуваним і додайте рядок у crontab, наприклад 30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1. Логуйте все і читайте лог — бекап, що тихо перестав запускатись, це класична історія катастрофи.
Огляд
cron виконує команди за розкладом і є на кожному Linux-сервері. Різниця між іграшковим налаштуванням і надійним невелика: абсолютні шляхи, вивід у лог, сповіщення при падінні задачі та періодичний тест відновлення.
Що потрібно мати
- Бекап-команду, яка вже працює вручну (див. бекапи через rsync).
- Базове знайомство із синтаксисом cron.
- SSH-автентифікацію за ключем для віддаленої цілі — cron не вміє вводити паролі.
Покрокова інструкція
- Створіть скрипт
/usr/local/bin/backup.sh:#!/bin/bash set -euo pipefail mysqldump --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz rsync -az --delete /var/www/ [email protected]:/srv/backups/www/ rsync -az /var/backups/ [email protected]:/srv/backups/db/ echo "$(date -Is) backup OK" - Зробіть його виконуваним:
chmod +x /usr/local/bin/backup.sh - Заплануйте (
crontab -e):30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 - Запустіть один раз вручну і переконайтесь, що рядок у лозі та віддалені файли з’явилися.
- Додайте сповіщення про збої — через
set -eбудь-яка помилка обриває скрипт, тож відсутній у лозі рядок "backup OK" означає збій; невеликий обгортковий скрипт може надіслати листа чи пінг. - Ротуйте старі дампи, щоб диск ніколи не заповнився:
find /var/backups -name 'db-*.sql.gz' -mtime +14 -delete
Типові проблеми
- Працює вручну, падає в cron: у cron мінімальний PATH — використовуйте абсолютні шляхи для кожного бінарника й файлу.
- Немає лога — немає уявлення: без
>> ... 2>&1помилки зникають; завжди перехоплюйте вивід. - Накладання запусків: довгі передачі можуть зіткнутися з наступним розкладом — обгорніть задачу у
flock, якщо запуски можуть перевищувати інтервал.
Коли звертатися в підтримку
Бекап-скрипти на unmanaged-планах Cloud2Y — на боці клієнта, але якщо задачі падають через сервер чи мережу (помилки I/O, обриви щоночі в один час), відкрийте тикет із витягами з лога.
Часті запитання
Чому скрипт працює вручну, але падає в cron?
cron запускається з мінімальним оточенням і PATH, тож команди й файли треба вказувати абсолютними шляхами, а будь-яке SSH-підключення потребує ключа, а не запиту пароля.
Як перехопити вивід cron-задачі бекапу?
Перенаправте stdout і stderr у рядку crontab, наприклад ">> /var/log/backup.log 2>&1". Без цього помилки зникають, і про збої ви дізнаєтесь на місяці пізніше, ніж треба.
Як запобігти накладанню запусків бекапу?
Обгорніть задачу у flock, напр. "flock -n /tmp/backup.lock /usr/local/bin/backup.sh" — тоді довга передача не зіткнеться з наступним запуском за розкладом і не пошкодить ціль.
Схожі статті
- Як налаштувати cron-задачі
- Як робити бекап Linux-сервера за допомогою rsync
- Як перевірити цілісність бекапів
- Типові помилки з бекапами
Потрібна допомога? Звернутися в підтримку Cloud2Y →
