Strategia backupów dla klienta IQHost
Plan backupów dla swojej strony — co, jak często, gdzie. Praktyczne strategie dla wizytówki, sklepu, aplikacji. 3-2-1 rule.
Backup to nie pojedynczy plik — to strategia. W tym tutorialu pokażemy plan backupów dla typowych scenariuszy: wizytówka, sklep, aplikacja produkcyjna, agencja z kilkoma klientami.
Co zyskasz
- Wybierzesz odpowiednią strategię dla swojej sytuacji.
- Zaplanujesz combinację IQBackups + Backuply + off-site.
- Wiesz co testować i jak często.
Wymagania wstępne
- Konto IQHost.
Złota zasada: 3-2-1
3 — kopie danych (oryginalna + 2 backup)
2 — różne nośniki (np. hosting + cloud)
1 — off-site (poza IQHost)
Spełnienie = bezpieczeństwo katastrofalne.
Wskazówka
W IQHost dostajesz IQBackups za darmo (retention 30 dni). To jeden z trzech kopii. Dodaj off-site (Dropbox / S3) i masz pełny 3-2-1.

Strategia per typ strony
Wizytówka firmowa (mała strona, rzadko zmieniana)
Zagrożenie: Niskie. Backup nie krytyczny, ale i tak warto.
Strategia:
| Co | Częstotliwość | Gdzie | Tool |
|---|---|---|---|
| Cały WP | Tygodniowo | IQBackups + Dropbox | IQBackups auto, DA Backup → rclone w cron |
Wystarczy. Restore raz w roku (jeśli w ogóle).
Blog osobisty / firmowy (zmiany cotygodniowe)
Zagrożenie: Średnie. Stracenie kilku postów = problem.
Strategia:
| Co | Częstotliwość | Gdzie |
|---|---|---|
| Pliki + DB | Codziennie | IQBackups (auto) |
| DB | Tygodniowo | Backuply → Dropbox |
| Pełny | Miesięcznie | DA Backup → pobierz lokalnie |
Wszystko jest, blogowanie spokojne.
Sklep WooCommerce (rejestracja transakcji)
Zagrożenie: WYSOKIE. Każda godzina utracone zamówienia = realny problem.
Strategia:
| Co | Częstotliwość | Gdzie |
|---|---|---|
| Cała baza | Co godzinę | Backuply incremental → Dropbox |
| Pełny WP | Codziennie | IQBackups (auto) |
| Pełny | Tygodniowo | DA Backup → S3 |
| Baza tylko | Realtime replication | Zewnętrzny serwer (MySQL replication — wymagane VPS) |
Realtime replication wymaga VPS / managed MySQL — overkill dla małych sklepów, must-have dla większych.
Aplikacja krytyczna (CRM, system rezerwacji)
Zagrożenie: Bardzo wysokie. Downtime = utrata zaufania klientów.
Strategia:
| Co | Częstotliwość | Gdzie |
|---|---|---|
| Baza | Co 5 min (incremental) | External |
| Pliki | Co godzinę | rsync → external server |
| Pełny | Codziennie | IQBackups + S3 |
| Failover | Real-time | Hot standby na VPS |
Pełna ochrona. Wymaga zewnętrznej infrastruktury.
Agencja z 20 klientami (multi-tenant)
Zagrożenie: Wysokie (rep risk).
Strategia: centralized backup system:
# Każdej nocy z external serwera:
for client in client1 client2 ... client20; do
ssh $client@host.iqhs.pl 'tar czf - /home/$USER/' > backups/$client/$(date +%Y%m%d).tar.gz
done
Plus rclone do S3. Wszyscy klienci backup'owani w jednym miejscu.
Co backupować priorytetowo
Hierarchia ważności:
- Baza danych (najtrudniej odtworzyć — unikalne dane klientów, posty)
- Pliki uploadowane (
wp-content/uploads/— niezamiennie) - Custom code (theme, plugins custom)
- Konfiguracja (
.htaccess,wp-config.php)
WordPress core, vendor pluginy — łatwe do reinstalacji. Nie tracisz danych.
Testowanie restore
Najważniejsza praktyka: regularnie testuj backup. Backup który nie odtwarza się = bezużyteczny.
Test plan:
- Raz na miesiąc: pobierz backup
- Stwórz staging (np.
staging.mojafirma.pl) - Restore tam
- Sprawdź czy działa
- Usuń staging
Jeśli restore nie działa — masz problem do rozwiązania zanim nastąpi disaster.
Wzór: codzienna automatyzacja
Cron (HS5+ SSH):
# Codzienny backup bazy o 2:00
0 2 * * * /usr/bin/mysqldump -u host36592_wp -pPASS host36592_wp | gzip > /home/host36592/backups/db-$(date +\%Y\%m\%d).sql.gz
# Codzienny backup plików (rsync diff) o 3:00
0 3 * * * rsync -av --delete /home/host36592/domains/mojafirma.pl/public_html/ /home/host36592/backups/files/
# Codziennie upload do Dropbox o 4:00
0 4 * * * /usr/bin/rclone sync /home/host36592/backups/ dropbox:Backups/host36592/
# Co tydzień (niedziela) czyść stare
0 5 * * 0 find /home/host36592/backups/ -mtime +30 -delete
Najczęstsze problemy
1. „Backup robi się, ale restore nie działa"
- Plik corrupt? Sprawdź
tar -tzf backup.tar.gz(jeśli zwraca błąd → backup nieważny) - Test restore lokalnie (jak wyżej)
2. „Disk full — backup'y zajmują wszystko"
- Retention policy — kasuj stare automatycznie
- Off-site — przenoś z lokalnego do cloud
- Zwiększ disk pakietu
3. „Backup zajmuje za długo — przekracza limity"
- Selektywnie (tylko najważniejsze)
- Incremental zamiast full
- Off-hours (nocą gdy mniej obciążenia)
4. „Mam wiele stron — zarządzanie jest chaosem"
Centralizuj — script z listą domen, robi backup wszystkich + sync off-site. Patrz wyżej Agency strategy.
5. „Backup do Dropbox — limit konta darmowego"
Dropbox free = 2 GB. Mało. Płatny Plus = 2 TB.
Alternatywa: Backblaze B2 ($6/TB/month) tańsze long-term.
6. „Czy mogę pominąć IQBackups bo mam własne?"
IQBackups jest darmowy — nie kosztuje Cię nic dodatkowo. Bezsensownie wyłączać. Dodaje warstwę bezpieczeństwa.
7. „Najlepsze praktyki"
- ✅ Wiele lokalizacji
- ✅ Test restore regularnie
- ✅ Automatyzacja (cron, nie manualne)
- ✅ Retention policy
- ✅ Monitoring (alert mailem gdy backup fail)
- ❌ Backup tylko na tym samym serwerze (gdzie produkcja)
- ❌ „Zrobię później" — najgorsza strategia
- ❌ Backup raz, nigdy nie testowany
Słowniczek
- RTO (Recovery Time Objective) — max czas niedostępności po incydencie.
- RPO (Recovery Point Objective) — max akceptowalna utrata danych.
- Failover — automatyczne przełączenie na zapasowy serwer.
- Hot standby — zapasowy serwer ready do natychmiastowego użycia.
Related

Feedback
Czy ten artykuł pomógł?