Резервне копіювання файлів сайту: інкрементні копії, S3/SFTP

Як налаштувати бекапування файлів сайту, щоб не втратити дані

Випадкове видалення папки uploads, збій диска на сервері або атака – без копії файлів сайт перетворюється на порожній каркас. Код з git відновлюється за хвилину, а от завантажені користувачами зображення, PDF, конфіги – ні. Ми — команда з 10+ років досвіду налаштування резервного копіювання. Пропонуємо налаштування під ключ: rsync на SFTP або синхронізацію з S3, ротацію, сповіщення та тестове відновлення. Оцінимо проект безкоштовно за 1 день. Резервне копіювання файлів – це не про "зберегти", а про "відновити". Без регулярної перевірки копій ви ризикуєте залишитися без даних у критичний момент. Ми гарантуємо, що після налаштування ви зможете відновити файли за кілька хвилин.

Які файли потрібно бекапити та чому?

Потрібно: завантажені користувачами файли (uploads/), SSL-сертифікати (якщо не Let's Encrypt), кастомні конфігурації поза репозиторієм. Не потрібно: код з git, node_modules, vendor, кеш додатку, тимчасові файли. Git вже зберігає історію — дублювати її в backup'у безглуздо. Важливо виключити великі папки з тимчасовими даними, щоб не витрачати місце та трафік. Інкрементний бекап дозволяє кожного разу копіювати лише змінені файли, що прискорює процес та знижує навантаження на сервер.

Як ми налаштовуємо бекапування: два підходи

Ми використовуємо два основні сценарії. Вибір залежить від бюджету та вимог до швидкості відновлення.

rsync + SSH на віддалений сервер

#!/bin/bash # /usr/local/bin/files-backup.sh set -euo pipefail SOURCE="/var/www/myapp/storage/app/uploads" BACKUP_HOST="backup.example.com" BACKUP_USER="backup" BACKUP_PATH="/backups/myapp/files" TIMESTAMP=$(date +%Y-%m-%d) # Инкрементальный backup через rsync (жёсткие ссылки для неизменённых файлов) rsync -avz \ --link-dest="${BACKUP_PATH}/latest" \ --exclude="*.tmp" \ --exclude=".DS_Store" \ -e "ssh -i /root/.ssh/backup_key -o StrictHostKeyChecking=no" \ "${SOURCE}/" \ "${BACKUP_USER}@${BACKUP_HOST}:${BACKUP_PATH}/${TIMESTAMP}/" # Обновить символическую ссылку на последний backup ssh -i /root/.ssh/backup_key "${BACKUP_USER}@${BACKUP_HOST}" \ "ln -sfn '${BACKUP_PATH}/${TIMESTAMP}' '${BACKUP_PATH}/latest'" echo "[$(date)] Files backup completed: ${TIMESTAMP}" 

AWS S3 синхронізація

# Ежедневная синхронизация uploads в S3 aws s3 sync /var/www/myapp/storage/app/uploads/ \ s3://myapp-backups/files/uploads/ \ --delete \ --exclude "*.tmp" \ --storage-class STANDARD_IA # S3 Lifecycle: автоматическое удаление через 90 дней aws s3api put-bucket-lifecycle-configuration \ --bucket myapp-backups \ --lifecycle-configuration file://lifecycle.json 

// lifecycle.json { "Rules": [{ "ID": "delete-old-backups", "Filter": { "Prefix": "files/" }, "Status": "Enabled", "Expiration": { "Days": 90 } }] } 

Порівняння rsync та S3 sync

S3 sync краще для хмарних проектів, rsync – якщо потрібен повний контроль над сервером зберігання.

Як вибрати між rsync та S3 для бекапу?

Якщо ваш сервер вже в AWS, S3 – природний вибір завдяки інтеграції та низькій ціні за зберігання STANDARD_IA. Якщо ви використовуєте виділений сервер у Selectel або Beget, rsync на другий сервер або SFTP-сховище буде простіше та дешевше. Ми допомагаємо визначитися з вибором на етапі аудиту. Важливо заздалегідь оцінити обсяг даних та частоту змін, щоб не переплатити за зберігання.

Як автоматизувати ротацію бекапів?

Ротація дозволяє не забивати місце старими копіями. Для S3 достатньо налаштувати Lifecycle policy: наприклад, зберігати щоденні копії 30 днів, щотижневі – 90 днів, щомісячні – 12 місяців. Для rsync можна використовувати скрипти з find та rm або готові рішення типу logrotate. Ми завжди налаштовуємо ротацію так, щоб залишалися точки відновлення на різні дати.

Що входить у налаштування під ключ

• Розробка скрипта бекапування (bash/ansible)
• Налаштування crontab з пріоритетом після backup БД
• Інтеграція сповіщень у Telegram/Slack (успіх/помилка)
• Налаштування ротації: S3 Lifecycle або rsync --delete-excluded
• Тестове відновлення на staging
• Документація: схема, контакти, інструкція з відновлення

Процес роботи

1. Аналітика: визначаємо, які директорії бекапити, вибираємо сховище (S3, SFTP, другий сервер).
2. Проектування: пишемо скрипт, налаштовуємо права доступу та SSH-ключі.
3. Реалізація: розгортаємо рішення на продакшені, налаштовуємо моніторинг.
4. Тестування: відновлюємо файли на тестовому оточенні, перевіряємо цілісність.
5. Деплой: фіксуємо crontab, передаємо документацію, навчаємо команду.

Терміни та вартість

Налаштування одного сценарію займає від 0.5 до 1 дня. Точна ціна залежить від обсягу даних та складності конфігурації. Наші рішення дозволяють скоротити витрати на зберігання до 50% порівняно з орендою додаткового сервера. Зв'яжіться з нами – оцінимо проект за 1 день.

Типові помилки при налаштуванні бекапів

• Ігнорування тестового відновлення – backup, який не можна відновити, марний.
• Зберігання backup'ів на тому ж диску, що й сайт (Raid не рятує від випадкового rm).
• Відсутність сповіщень – збій може залишитися непоміченим тижнями.

Гарантія: всі налаштовані backup'и проходять тест відновлення перед передачею замовнику.

Чому важливо тестувати відновлення?

Без тестового відновлення ви не знаєте, чи працює backup. Ми завжди відновлюємо файли на staging-оточенні та перевіряємо цілісність через md5sum або порівняння кількості файлів. rsync рекомендує використовувати опцію --dry-run для перевірки.

Замовте консультацію: ми проаналізуємо вашу інфраструктуру та запропонуємо оптимальне рішення.

Рекомендована ротація бекапів

На одному з проектів ми виявили, що бекапи не працювали через помилку в crontab. Після налаштування за нашою схемою час відновлення скоротився з 4 годин до 15 хвилин.