Автоматичне резервне копіювання є основою для роботи будь-яких виробничих систем на VPS під управлінням Linux. Навіть стабільний сервер може зазнати наслідків випадкового видалення, пошкодження файлової системи, невдалих оновлень або злому облікового запису.
У цьому посібнику наведено практичну схему резервного копіювання: що слід включити, як створювати щоденні архіви, як зберігати копії поза межами локації та як перевіряти відновлення. Якщо ви хостите реальні проекти, почніть із надійного VPS на базі Linux із достатнім обсягом пам’яті та стабільною продуктивністю диска, щоб виконувати резервне копіювання без впливу на користувачів.
Перш ніж писати будь-які скрипти, визначте просту стратегію. Це підвищує надійність, а також значно полегшує усунення несправностей у майбутньому.
Для більшості веб-сайтів та додатків набір резервних копій, який «обов’язково потрібно мати», виглядає так:
/var/www/)/etc/)/home/)/etc/letsencrypt/ або у шляхах конфігурації вашого веб-сервера)Порада: Якщо ваш VPS використовується для контейнерів (Docker), зазвичай потрібно створювати резервні копії постійних томів та конфігурацій додатків, а не шарів контейнерів.
Створіть спеціальну папку для резервних копій із суворими правами доступу. Це запобігає доступу інших користувачів/процесів до конфіденційних резервних копій.
sudo mkdir -p /backup
sudo chown root:root /backup
sudo chmod 700 /backupВажливо: Переконайтеся, що шлях до резервних копій не знаходиться всередині каталогу вашого веб-сайту (наприклад, не в папці /var/www), інакше ви можете випадково оприлюднити архіви через HTTP.
Щоденний стиснений архів — це хороший базовий варіант. Використовуйте виключення, щоб уникнути резервного копіювання віртуальних файлових систем та запобігти рекурсивним саморезервуванням.
sudo tar -czf /backup/backup-$(date %F).tar.gz
--one-file-system
--exclude=/backup
--exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run
/var/www /etc /homeЯкщо ваш VPS завантажений, ви можете зменшити навантаження від резервного копіювання, використовуючи пріоритет процесора та вводу-виводу:
sudo nice -n 19 ionice -c3 tar -czf /backup/backup-$(date %F).tar.gz
--one-file-system
--exclude=/backup
--exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run
/var/www /etc /home-c — створити архів-z — стиснення gzip-f — вихідний файл--one-file-system — не перетинати точки монтування (допомагає уникнути несподіванок)Для більшості виробничих серверів самих файлів недостатньо. Додайте дампи баз даних до вашої процедури резервного копіювання (бажано зберігати їх разом з архівами).
sudo mysqldump --all-databases --single-transaction --routines --events
| gzip > /backup/mysql-all-$(date %F).sql.gzПорада: Для автоматизації безпечно налаштуйте облікові дані (наприклад, у /root/.my.cnf) замість того, щоб вказувати паролі в cron.
sudo -u postgres pg_dumpall | gzip > /backup/postgres-all-$(date %F).sql.gzЗавжди перевіряйте, чи файли існують і чи можна їх прочитати. Архів розміром у нуль байт або пошкоджений дамп можуть з’явитися непомітно, якщо ви ніколи не перевіряєте.
ls -lh /backuptar -tzf /backup/backup-$(date %F).tar.gz | headДля більшої впевненості генеруйте контрольні суми (корисно для передачі даних за межі локації):
cd /backup
sha256sum backup-$(date %F).tar.gz > backup-$(date %F).tar.gz.sha256Замість складних однорядкових команд у cron, вкладіть свою логіку у скрипт. Це значно спростить ведення журналу, зберігання та синхронізацію за межами сайту.
sudo nano /usr/local/sbin/backup-vps.shПриклад скрипта (відредагуйте шляхи відповідно до вашого сервера):
#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/backup"
DATE="$(date %F)"
HOST="$(hostname -s)"
RETENTION_DAYS="7"
ARCHIVE="${BACKUP_DIR}/${HOST}-files-${DATE}.tar.gz"
MYSQL_DUMP="${BACKUP_DIR}/${HOST}-mysql-${DATE}.sql.gz"
PG_DUMP="${BACKUP_DIR}/${HOST}-postgres-${DATE}.sql.gz"
mkdir -p "${BACKUP_DIR}"
chmod 700 "${BACKUP_DIR}"
# 1) Files archive (adjust folders if needed)
nice -n 19 ionice -c3 tar -czf "${ARCHIVE}"
--one-file-system
--exclude=/backup
--exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run
/var/www /etc /home
# 2) MySQL/MariaDB dump (optional: remove if you don't use MySQL)
if command -v mysqldump >/dev/null 2>&1; then
mysqldump --all-databases --single-transaction --routines --events
| gzip > "${MYSQL_DUMP}" || true
fi
# 3) PostgreSQL dump (optional: remove if you don't use PostgreSQL)
if command -v pg_dumpall >/dev/null 2>&1 && id postgres >/dev/null 2>&1; then
sudo -u postgres pg_dumpall | gzip > "${PG_DUMP}" || true
fi
# 4) Checksums (helpful for integrity checks after transfers)
cd "${BACKUP_DIR}"
sha256sum "$(basename "${ARCHIVE}")" > "$(basename "${ARCHIVE}").sha256"
# 5) Retention cleanup
find "${BACKUP_DIR}" -type f -name "${HOST}-files-*.tar.gz" -mtime "${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "${HOST}-mysql-*.sql.gz" -mtime "${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "${HOST}-postgres-*.sql.gz" -mtime "${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "${HOST}-files-*.tar.gz.sha256" -mtime "${RETENTION_DAYS}" -delete
echo "Backup completed: ${DATE}"Зробіть його виконуваним:
sudo chmod x /usr/local/sbin/backup-vps.shЗаплануйте щоденне виконання скрипта (наприклад, о 03:00). Відредагуйте кореневий crontab:
sudo crontab -eДодайте наступний рядок:
0 3 * * * /usr/local/sbin/backup-vps.sh >> /var/log/backup-vps.log 2>&1Порада: Перевірте журнали після першого запуску: tail -n 50 /var/log/backup-vps.log
Не зберігайте резервні копії лише на тому самому VPS. Основним і надійним підходом є копіювання резервних копій на другий сервер за допомогою rsync через SSH.
sudo ssh-keygen -t ed25519 -a 64 -f /root/.ssh/id_ed25519 -N ""sudo ssh-copy-id backupuser@remote-serversudo rsync -az /backup/ backupuser@remote-server:/remote-backup/$(hostname -s)/Якщо ви хочете, щоб цей процес був автоматизований, заплануйте його після створення резервної копії (наприклад: 03:30):
30 3 * * * rsync -az /backup/ backupuser@remote-server:/remote-backup/$(hostname -s)/ >> /var/log/backup-vps-rsync.log 2>&1Принаймні час від часу виконуйте тестове відновлення у тимчасовий каталог. Це найшвидший спосіб виявити проблеми з правами доступу, відсутні шляхи або пошкоджені архіви.
sudo mkdir -p /tmp/restore-test
sudo tar -xzf /backup/$(hostname -s)-files-$(date %F).tar.gz -C /tmp/restore-test
ls -la /tmp/restore-test | headА також перевіряйте контрольні суми, якщо ви їх використовуєте:
cd /backup
sha256sum -c $(hostname -s)-files-$(date %F).tar.gz.sha256/backup приватними: chmod 700 і належними root.Якщо резервне копіювання займає занадто багато часу, під час стиснення спостерігаються стрибки завантаження процесора або вхід/вихід диска стає вузьким місцем, ви отримаєте більш передбачувану автоматизацію на потужнішому VPS під управлінням Linux з кращою продуктивністю системи зберігання даних та додатковими ресурсами — особливо якщо ви використовуєте великі бази даних або керуєте декількома веб-сайтами.
Для більшості сайтів щоденні резервні копії — це мінімум. Якщо дані часто змінюються (замовлення, повідомлення, завантаження), розгляньте можливість більш частого створення дампів бази даних (наприклад, кожні 1–6 годин) з більш тривалим терміном зберігання.
Ні. Знімки можуть бути корисними, але вони не є повноцінною стратегією резервного копіювання. Вам все одно потрібні незалежні копії поза межами сайту та тестування відновлення.
Простий і ефективний підхід — це 7 щоденних резервних копій плюс щотижневі/щомісячні архіви для тривалішого зберігання, залежно від потреб вашого бізнесу та бюджету на зберігання даних.
Зберігання резервних копій лише на тому самому VPS та відсутність тестування відновлення. Тестування відновлення поза місцем розташування — це те, що перетворює «резервні копії» на реальне відновлення.
Хочете передбачувані завдання резервного копіювання, стабільну продуктивність та достатньо місця для архівів і дампів баз даних? Почніть із надійного VPS на базі Linux та автоматизуйте щоденне резервне копіювання та синхронізацію поза майданчиком із першого дня.
