BEZPIECZEńSTWO I KOPIE ZAPASOWE • 5 MIN READ

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.

Zespół IQHost 14 maj 2026 5m read
#IQHost #backup #hosting

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.

Strona Backup w DA — kompleksowe podejście

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:

  1. Baza danych (najtrudniej odtworzyć — unikalne dane klientów, posty)
  2. Pliki uploadowane (wp-content/uploads/ — niezamiennie)
  3. Custom code (theme, plugins custom)
  4. 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:

  1. Raz na miesiąc: pobierz backup
  2. Stwórz staging (np. staging.mojafirma.pl)
  3. Restore tam
  4. Sprawdź czy działa
  5. 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

Plugin Backuply — strategia retention

Feedback

Czy ten artykuł pomógł?

Potwierdź