Dlaczego S3 pasuje do backupów
Backup trzymany obok danych produkcyjnych bywa złudnym zabezpieczeniem. Awaria serwera, pełny dysk lub błąd człowieka potrafią skasować wszystko naraz. S3 rozdziela role: dane kopii są poza serwerem, proces jest łatwy do automatyzacji, a dostęp można ograniczyć do minimum.
3-2-1 bez przesady
Trzy kopie, dwa nośniki, jedna kopia poza główną lokalizacją. Dla większości stron wystarczy: krótka retencja lokalna (1–3 dni) i dłuższa retencja w S3 (np. 7 dziennych + 4 tygodniowe + 6 miesięcznych). Najważniejsze jest to, żebyś potrafił odtworzyć dane szybko i według jasnego scenariusza.
Backup strony do S3: WordPress, Laravel, statyczne strony
Prawie zawsze masz dwa elementy: pliki + baza.
WordPress:
Laravel:
Statyczne strony: archiwum katalogu + wysyłka do S3. Jeśli źródło żyje w Git, często backupujesz tylko wynik builda i konfiguracje.
Backup bazy: MySQL/PostgreSQL + szyfrowanie + retencja
MySQL/MariaDB:
PostgreSQL:
Szyfrowanie (GPG):
Retencję ustawiasz lokalnie krótko, a w S3 dłużej przez reguły lifecycle.
rclone + S3: “jak dysk” i synchronizacja
Do historii backupów zwykle bezpieczniej jest copy niż sync, bo sync usuwa pliki w miejscu docelowym.
Montowanie jak dysk:
Borg/Restic + S3: deduplikacja i szybkie inkrementy
Zamiast codziennie wysyłać pełne archiwa, Borg/Restic utrzymują repozytorium z deduplikacją — wysyłasz tylko różnice. To tańsze i szybsze, a odtwarzanie bywa bardziej przewidywalne.
Restic (logika):
Wersjonowanie S3 bez “śmieci”
Wersjonowanie bywa zdradliwe: każdy overwrite tworzy kolejną wersję, a stare zostają. Żeby nie przepłacać, ustaw lifecycle dla nieaktualnych wersji (np. 14–30 dni), czyść niedokończone multipart uploady i oddziel dane w prefixach/bucketach.