Чому S3 — це “правильне місце” для бекапів

Найгірший бекап — це бекап, який лежить поруч із тим, що він має рятувати. Якщо сервер упав, диск заповнився або хтось видалив дані — “локальна копія” часто зникає разом з проблемою. S3-сховище логічно вирішує цю пастку: бекапи живуть окремо від сервера, їх легко автоматизувати, а доступ можна жорстко обмежити під задачу “тільки запис” або “тільки читання”.

3-2-1 без оверкілу: як зібрати здорову схему

Сенс 3-2-1 простий: 3 копії, 2 різні носії, 1 копія поза основною локацією. Для більшості сайтів це можна зробити без складних систем:

  • перша копія — “робочі дані” на сервері;

  • друга — локальний бекап на цьому ж сервері або на іншій машині (короткий термін, наприклад 1–3 дні);

  • третя — S3 як віддалене сховище з ротацією за періодами (наприклад: 7 щоденних, 4 тижневих, 6 місячних).

Фокус тут не в кількості “галочок”, а в тому, щоб ти реально міг відновитися за зрозумілим сценарієм.

Потрібен VPS/VDS?
Запусти сервер за хвилину та
отримай підтримку 24/7
Замовити VPS

Як бекапити сайт у S3: WordPress, Laravel, статичні сайти

Є універсальна логіка: файли + база. Файли — це код/контент/завантаження, база — це “життя” сайту.

WordPress: файлові дані + дамп БД

Найчастіше достатньо архівувати wp-content (теми, плагіни, uploads) і робити дамп БД. Сам core WordPress за потреби легко відновлюється з дистрибутива, а от контент — ні.

Приклад під cron (ідея, яку легко адаптувати):

 
# 1) Дамп БД mysqldump --single-transaction -uDBUSER -p'DBPASS' DBNAME | gzip > /backup/wp-db-$(date +%F).sql.gz # 2) Архів wp-content tar -czf /backup/wp-content-$(date +%F).tar.gz /var/www/site/wp-content # 3) Відправка в S3 через rclone (або aws cli) rclone copy /backup remote-s3:backups/site/wp/ --transfers=4

Laravel: “важка” частина — storage та env-логіка

У Laravel зазвичай важливо не забути storage/app, storage/framework (не все треба), storage/logs (зазвичай не треба в бекап), і користувацькі завантаження, якщо вони зберігаються локально. Далі — дамп БД і відправка в S3. Якщо статичні файли/кеші генеруються автоматично — їх у бекап краще не тягнути, щоб не роздувати обсяг.

Базова схема:

 
tar -czf /backup/laravel-files-$(date +%F).tar.gz \ /var/www/app/storage/app \ /var/www/app/public/uploads pg_dump -Fc -U DBUSER DBNAME > /backup/laravel-db-$(date +%F).dump rclone copy /backup remote-s3:backups/site/laravel/

Статичні сайти: простіше не буває

Статика — ідеальний кандидат для швидких бекапів. Якщо сайт збирається з репозиторію, інколи достатньо бекапити тільки “вміст” (build) і конфіги, а “джерело” і так живе в Git. Але якщо статика редагується руками на сервері — архівуй папку сайту і відправляй у S3.

Бекап БД у S3: MySQL/PostgreSQL + шифрування + ротація

У базі даних зберігається найцінніше, тому до неї ставляться суворіше: дамп має бути консистентним, зашифрованим і з ротацією.

MySQL / MariaDB (консистентно для InnoDB):

 
mysqldump --single-transaction --quick -uDBUSER -p'DBPASS' DBNAME | gzip > /backup/db-$(date +%F).sql.gz

PostgreSQL (зручно у форматі custom):

 
pg_dump -Fc -U DBUSER DBNAME > /backup/db-$(date +%F).dump

Шифрування (простий та надійний варіант — GPG):

 
gpg --batch --yes --symmetric --cipher-algo AES256 \ --passphrase "$BACKUP_PASSPHRASE" \ /backup/db-$(date +%F).dump

Після цього відправляєш у S3, а локально тримаєш коротку “гарячу” історію (наприклад 1–3 дні), щоб швидко відновлюватися без скачування з мережі.

Ротація краще робиться двома рівнями:

  • на сервері: видаляєш старі файли за N днів (find /backup -type f -mtime +3 -delete);

  • у S3: задаєш політики життєвого циклу (щоб старі точки відкату не накопичувались вічно).

rclone + S3: “хмара як диск” і синхронізація

rclone зручний тим, що з ним S3 починає виглядати як звичне сховище: копіювання, синхронізація, перевірки, ліміти швидкості. Для бекапів важливо не плутати copy і sync: sync видаляє зайве на стороні призначення, тому для історії бекапів частіше використовують copy (щоб нічого випадково не стерти).

Типовий шаблон:

 
rclone copy /backup remote-s3:backups/site/ --transfers=4 --checkers=8 rclone lsf remote-s3:backups/site/

А якщо треба “як диск” для робочих процесів — можна монтувати:

 
rclone mount remote-s3:backups /mnt/s3 --vfs-cache-mode full

Borg/Restic + S3: коли хочеться швидко і економно

Borg і Restic цінні тим, що вони роблять дедуплікацію та інкременти: ти не заливаєш щодня повний архів на терабайт, а відправляєш тільки різницю. Це економить і час, і місце, і нерви. Плюс відновлення часто швидше, ніж із “купи архівів”, бо інструмент тримає структурований репозиторій.

Restic (приклад логіки):

 
export RESTIC_REPOSITORY="s3:s3.example.com/backups/site" export RESTIC_PASSWORD="$RESTIC_PASS" restic backup /var/www/site /etc/nginx restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune restic snapshots

Це виглядає як нормальний процес, а не як “архіви, які колись знадобляться”.

Версіонування в S3: як не переплачувати за сміття

Версіонування — корисне, але підступне. Воно може тихо подвоїти або потроїти споживання, якщо у тебе часто перезаписуються великі файли або ти активно використовуєш синхронізацію. Суть проста: кожне “оновлення” створює нову версію, а стара залишається лежати.

Щоб версіонування було вигідним:

  • вмикай його там, де це реально потрібно (критичні файли/бекапи, а не будь-які тимчасові дані);

  • налаштовуй lifecycle на старі версії: наприклад, тримати попередні версії 14–30 днів і видаляти;

  • слідкуй за “delete markers” і незавершеними multipart-upload — це теж може накопичувати сміття;

  • розділяй бакети або префікси: “backups/” окремо, “uploads/” окремо, щоб правила не змішувалися.

Потрібен виділений сервер?
Потужні конфігурації та
швидкий запуск під ключ
Обрати сервер