Backup, którego naprawdę używasz
Większość firm dowiaduje się, że ich backup nie działa, dopiero w momencie awarii. Dlatego radzimy traktować backup jako proces, a nie odhaczony punkt: automatyczne kopie, przechowywane poza serwerem produkcyjnym, i regularnie testowane przywracanie. W cPanel codzienny backup działa automatycznie i przywracasz go z panelu; na VPS i serwerach dedykowanych zespół DevOps może skonfigurować cykliczne testy przywracania w ramach wliczonych godzin.
Jaki backup obejmuje każdy plan
Hosting cPanel ma codzienny automatyczny backup, który przywracasz z panelu. VPS ma snapshoty — pełne kopie stanu serwera — bez gwarantowanej częstotliwości. Serwery dedykowane domyślnie nie zawierają backupu: dyski NVMe są montowane parami, a RAID konfigurujemy przy instalacji, ale RAID to nie backup. Zewnętrzny backup, PITR dla baz danych i testy przywracania konfiguruje zespół w ramach wliczonych godzin DevOps (5–10 h/mies. na serwerach dedykowanych).
| Plan | Backup | Przywracanie | Lokalizacja |
|---|---|---|---|
| cPanel Hosting | Codzienny automatyczny backup | Z panelu klienta | UE (Frankfurt) |
| VPS | Snapshoty, bez gwarantowanej częstotliwości | Ze snapshotu | UE (Frankfurt) |
| VPS — backup zewnętrzny | Na życzenie, w ramach godzin DevOps | Według skonfigurowanej strategii | Ustalana z zespołem |
| Serwer dedykowany | Domyślnie niewliczony — konfigurowany na życzenie | Według strategii (3-2-1, PITR) | UE (Frankfurt) + zewnętrzny magazyn na życzenie |
RPO i RTO — wartości, które warto ustalić samemu
Zamiast „backup jak najszybciej" warto ustalić dwie konkretne wartości. RPO (Recovery Point Objective) mówi, ile danych możesz stracić. RTO (Recovery Time Objective) mówi, jak długo może trwać przywracanie. Na ich podstawie zespół konfiguruje strategię.
Maksymalna utrata danych, jaką akceptujesz. Codzienny backup oznacza do jednego dnia strat; z WAL streaming baza danych schodzi poniżej minuty — konfigurowane na życzenie.
Czas przywracania zależy od ilości danych i wybranej strategii. Nie gwarantujemy RTO — wiarygodna jest tylko wartość zmierzona w teście przywracania.
Scenariusze awarii — i jak się przed nimi chronić
Awarie zdarzają się rzadko, ale mają duży wpływ. Oto najczęstsze scenariusze i zabezpieczenie, które zalecamy dla każdego z nich. Na VPS i serwerach dedykowanych zespół konfiguruje te zabezpieczenia w ramach wliczonych godzin DevOps.
Awaria sprzętu (dysk, RAM)
Najczęstsza przyczyna utraty danych. Serwery dedykowane mają dyski NVMe w parach z RAID konfigurowanym przy instalacji, a plany EPYC i Xeon pamięć ECC. RAID utrzymuje serwer w działaniu przy awarii jednego dysku, ale nie zastępuje backupu — zewnętrzna kopia nadal jest potrzebna.
Ochrona: RAID + backup zewnętrznyRansomware lub kompromitacja konta
Atakujący szyfruje pliki na serwerze — i każdą kopię, do której serwer ma dostęp. Dlatego przynajmniej jedna kopia powinna leżeć poza serwerem, tam gdzie konto produkcyjne nie może jej zmienić (niezmienna lub offline). Konfigurujemy ją na życzenie, w ramach godzin DevOps.
Ochrona: izolowana kopiaPrzypadkowe usunięcie danych
„DROP TABLE users" wykonane na produkcji. Najczęstszy ludzki błąd. Jeśli baza ma skonfigurowane point-in-time recovery (PITR), wracasz do chwili tuż przed błędem; codzienny backup cofa cię tylko do ostatniej kopii.
Ochrona: PITR na życzenieAwaria całego DC
Pożar, zalanie, dłuższy outage operatora. Ochroną jest kopia w innej lokalizacji, np. w drugim DC. Replikacja i failover nie są domyślnie wliczone; zespół konfiguruje je na życzenie, w ramach godzin DevOps.
Ochrona: kopia w innej lokalizacjiBug w aplikacji uszkadza dane
Deploy wprowadza błąd, który psuje rekordy w bazie. Mając osobny backup bazy, przywracasz tylko bazę (nie cały serwer) — pliki aplikacji zostają, dane wracają.
Ochrona: osobny backup bazyMigracja na inny serwer
Przerastasz obecny plan. VPS przechodzi na wyższy plan z większą liczbą vCPU, RAM i dysku; przy przeprowadzce na inny serwer planujemy migrację z wyprzedzeniem, żeby przestój był krótki.
Rada: zaplanuj migrację wcześniejBackup baz danych — strategie per silnik
Pełny backup VPS-a nie zawsze wystarcza. Bazy danych mają własne mechanizmy point-in-time recovery (PITR) — pozwalają wrócić do dokładnie wybranego momentu, a nie tylko do ostatniego snapshotu. Konfigurujemy je na życzenie, w ramach wliczonych godzin DevOps.
Co jest w cenie — a co konfigurujemy na życzenie
Nie ma osobno sprzedawanego „premium backupu": to, co jest wliczone, opisuje każdy plan, a wszystko ponad to zespół buduje w ramach godzin DevOps z twojego abonamentu. Godziny ponad limit są rozliczane osobno, godzinowo.
- cPanel: codzienny automatyczny backup, przywracanie z panelu — w cenie
- VPS: snapshoty, bez gwarantowanej częstotliwości — w cenie
- Serwery dedykowane: dyski NVMe w parach, RAID konfigurowany przy instalacji — backup domyślnie niewliczony
- Zewnętrzny backup według zasady 3-2-1 — na życzenie, w ramach godzin DevOps (5–10 h/mies. na serwerach dedykowanych)
- PITR dla baz danych (WAL, binlog, oplog) — na życzenie, w ramach godzin DevOps
- Testy przywracania i okres retencji — ustalane z zespołem i konfigurowane w ramach godzin DevOps
Przywracanie backupu — w 4 krokach
Otwórz panel
Zaloguj się do panelu klienta. W cPanel przywracasz tam codzienny backup, na VPS wybierasz snapshot.
Wybierz punkt czasowy
Wybierz kopię ze stanem sprzed problemu. Najnowsza nie zawsze jest właściwa, jeśli błąd istnieje od dłuższego czasu.
Kliknij „Restore"
Przywracanie nadpisuje obecny stan. Jeśli nie masz pewności, poproś zespół, by najpierw przywrócił kopię w osobnym środowisku do porównania.
Sprawdź wynik
Sprawdź, czy aplikacja działa, a dane są na swoim miejscu. Czas przywracania zależy od ilości danych.
Częste pytania
Czy snapshot wymaga zatrzymania serwera?
Zwykle nie: snapshot VPS-a powstaje przy działającym serwerze. W przypadku bazy danych snapshot działającego serwera nie zawsze jest spójny, dlatego zalecamy osobny backup bazy (dump lub WAL/binlog), który zespół konfiguruje na życzenie.
Jak długo trwa restore z bardzo dużego snapshotu (np. 500 GB)?
Zależy od ilości danych, dysku i miejsca przechowywania kopii — z kopii zewnętrznej trwa to dłużej niż z lokalnej. Nie obiecujemy stałego czasu: realną wartość daje test przywracania, który możemy przeprowadzić razem z tobą.
Czy backupy są szyfrowane?
Szyfrowanie zewnętrznych backupów jest częścią strategii, którą konfigurujemy na życzenie — np. kopie opuszczające serwer wyłącznie w postaci zaszyfrowanej, z kluczami trzymanymi osobno od produkcji. Przekaż zespołowi swoje wymagania, zamawiając konfigurację.
Co jeśli chcę dłuższą retencję niż 30 dni?
Retencję zewnętrznych backupów ustala się podczas konfiguracji strategii, zależnie od twoich potrzeb i prawnych obowiązków archiwizacji. Miejsce na dłuższą retencję ustalasz z zespołem; plany znajdziesz w cenniku.
Czy mogę pobrać snapshot lokalnie?
Na VPS i serwerach dedykowanych masz dostęp root i kopiujesz dane wybranymi narzędziami (rsync, tar). Zespół może też, w ramach godzin DevOps, skonfigurować automatyczne kopie do zewnętrznego magazynu, np. AWS S3, Google Cloud Storage lub Azure Blob.
Twoje dane są zbyt cenne, by polegać na szczęściu
cPanel ma codzienny backup, a VPS snapshoty. Na serwerach dedykowanych zespół buduje strategię backupu w ramach wliczonych godzin DevOps. Sprawdź szczegóły w cenniku.
Zobacz plany →