Rezerves kopija, kuru tiešām izmantojat
Vairums uzņēmumu uzzina, ka rezerves kopija nedarbojas, tikai tad, kad notiek katastrofa. Tāpēc iesakām rezerves kopēšanu uztvert kā procesu, nevis ķeksīti: automātiskas kopijas, kas glabājas atsevišķi no produkcijas servera, un regulāri pārbaudīta atjaunošana. cPanel ikdienas rezerves kopija tiek veidota automātiski, un to atjaunojat no paneļa; VPS un veltītajos serveros DevOps komanda no jūsu iekļautajām stundām var ieplānot atjaunošanas testus.
Kādu rezerves kopiju iekļauj katra pakete
cPanel mitināšanai ir automātiska ikdienas rezerves kopija, ko atjaunojat no paneļa. VPS ir momentuzņēmumi — pilnas servera stāvokļa kopijas — bez garantētas biežuma. Veltītajos serveros rezerves kopija pēc noklusējuma nav iekļauta: NVMe diski ir pārī un RAID tiek uzstādīts instalēšanas laikā, taču RAID nav rezerves kopija. Ārējo rezerves kopiju, datubāzu PITR un atjaunošanas testus uzstāda mūsu komanda no iekļautajām DevOps stundām (5–10 h/mēnesī veltītajiem serveriem).
| Pakete | Rezerves kopija | Atjaunošana | Atrašanās vieta |
|---|---|---|---|
| cPanel mitināšana | Automātiska ikdienas rezerves kopija | No klientu paneļa | ES (Frankfurte) |
| VPS | Momentuzņēmumi, bez garantēta biežuma | No momentuzņēmuma | ES (Frankfurte) |
| VPS — ārējā rezerves kopija | Pēc pieprasījuma, no DevOps stundām | Atbilstoši konfigurētajai stratēģijai | Saskaņojams ar komandu |
| Veltītais serveris | Pēc noklusējuma nav iekļauta — uzstāda pēc pieprasījuma | Atbilstoši stratēģijai (3-2-1, PITR) | ES (Frankfurte) + ārējā krātuve pēc pieprasījuma |
RPO un RTO — skaitļi, kas jānosaka pašiem
Rezerves kopijas „pēc iespējas ātrāk” vietā ir vērts noteikt divas konkrētas vērtības. RPO (Recovery Point Objective) norāda, cik datu varat atļauties zaudēt. RTO (Recovery Time Objective) norāda, cik ilgi drīkst ilgt atjaunošana. Komanda veido stratēģiju ap šīm vērtībām.
Maksimālie datu zudumi, ko varat pieņemt. Ikdienas rezerves kopija nozīmē līdz pat vienas dienas zudumu; ar WAL straumēšanu datubāze nokļūst zem vienas minūtes — uzstāda pēc pieprasījuma.
Atjaunošanas laiks ir atkarīgs no datu apjoma un izvēlētās stratēģijas. RTO negarantējam — vienīgais uzticamais rādītājs ir tas, kas izmērīts atjaunošanas testā.
Katastrofu scenāriji — un kā pasargāties
Katastrofas ir retas, bet ar lielu ietekmi. Šeit ir biežākie scenāriji un aizsardzība, ko katram iesakām. VPS un veltītajos serveros šos pasākumus uzstāda komanda no iekļautajām DevOps stundām.
Aparatūras atteice (disks, RAM)
Visbiežākais datu zuduma cēlonis. Veltītajiem serveriem ir pārī savienoti NVMe diski ar RAID, kas uzstādīts instalēšanas laikā, kā arī ECC RAM EPYC un Xeon līmeņos. RAID uztur serveri darbībā, ja disks sabojājas, taču tas neaizstāj rezerves kopiju — ārēja kopija joprojām ir nepieciešama.
Aizsardzība: RAID + ārējā rezerves kopijaIzspiedējvīruss vai konta kompromitēšana
Uzbrucējs šifrē servera failus — un jebkuru kopiju, kurai serveris var piekļūt. Tāpēc vismaz vienai kopijai jāatrodas ārpus servera, kur produkcijas konts to nevar mainīt (nemaināma vai bezsaistes). Uzstādām pēc pieprasījuma, no DevOps stundām.
Aizsardzība: izolēta kopijaNejauša datu dzēšana
„DROP TABLE users”, izpildīts produkcijā. Visbiežākā cilvēka kļūda. Ja datubāzei ir uzstādīta atjaunošana uz laika punktu (PITR), varat atgriezties tieši pirms kļūdas; ikdienas rezerves kopija atgriež tikai līdz pēdējai kopijai.
Aizsardzība: PITR pēc pieprasījumaPilnīgs datu centra atteikums
Ugunsgrēks, plūdi, ilgstošs operatora pārtraukums. Aizsardzība ir kopija citā atrašanās vietā, piemēram, otrā datu centrā. Replikācija un pārslēgšanās uz rezervi pēc noklusējuma nav iekļauta; komanda tās uzstāda pēc pieprasījuma, no DevOps stundām.
Aizsardzība: kopija citā atrašanās vietāLietotnes kļūda bojā datus
Izvietošana ievieš kļūdu, kas sabojā datubāzes ierakstus. Ar atsevišķu datubāzes rezerves kopiju atjaunojat tikai datubāzi (nevis visu serveri) — lietotnes faili paliek, dati tiek atritināti atpakaļ.
Aizsardzība: atsevišķa datubāzes rezerves kopijaMigrācija uz citu serveri
Jūs izaugat no pašreizējās paketes. VPS var pāriet uz augstāku līmeni ar vairāk vCPU, RAM un diska; pārejai uz citu serveri migrāciju plānojam iepriekš, lai dīkstāve būtu īsa.
Ieteikums: plānojiet migrāciju savlaicīgiDatubāzu rezerves kopijas — stratēģijas katram dzinējam
Pilna VPS rezerves kopija ne vienmēr ir pietiekama. Datubāzēm ir savi atjaunošanas uz laika punktu (PITR) mehānismi — tie ļauj atgriezties tieši izvēlētajā brīdī, nevis tikai pie pēdējā momentuzņēmuma. Mēs tos uzstādām pēc pieprasījuma, no iekļautajām DevOps stundām.
Kas ir iekļauts — un kas tiek uzstādīts pēc pieprasījuma
Atsevišķi netiek pārdota „premium rezerves kopija”: iekļautais ir norādīts katrai paketei, un visu pārējo komanda izveido no jūsu abonementā iekļautajām DevOps stundām. Stundas virs kvotas tiek rēķinātas atsevišķi, pēc stundu likmes.
- cPanel: automātiska ikdienas rezerves kopija, atjaunošana no paneļa — iekļauta
- VPS: momentuzņēmumi, bez garantēta biežuma — iekļauti
- Veltītie serveri: NVMe diski pārī, RAID uzstādīts instalēšanas laikā — rezerves kopija pēc noklusējuma nav iekļauta
- Ārējā rezerves kopija pēc 3-2-1 noteikuma — pēc pieprasījuma, no DevOps stundām (5–10 h/mēnesī veltītajiem serveriem)
- Datubāzu PITR (WAL, binlog, oplog) — pēc pieprasījuma, no DevOps stundām
- Atjaunošanas testi un glabāšanas termiņš — saskaņo ar komandu un uzstāda no DevOps stundām
Rezerves kopijas atjaunošana — 4 soļos
Atveriet paneli
Pieslēdzieties klientu panelim. cPanel tur atjaunojat ikdienas rezerves kopiju; VPS izvēlaties momentuzņēmumu.
Izvēlieties laika punktu
Izvēlieties kopiju tieši pirms problēmas. Jaunākā ne vienmēr ir pareizā, ja kļūda pastāv jau kādu laiku.
Noklikšķiniet uz „Atjaunot”
Atjaunošana pārraksta pašreizējo stāvokli. Ja neesat pārliecināti, lūdziet komandu vispirms atjaunot atsevišķā vidē, lai varētu salīdzināt.
Pārbaudiet rezultātu
Pārbaudiet, vai lietotne darbojas un dati ir tur, kur tiem jābūt. Atjaunošanas ilgums ir atkarīgs no datu apjoma.
Biežāk uzdotie jautājumi
Vai momentuzņēmumam jāapstādina serveris?
Parasti nē: VPS momentuzņēmums tiek veidots, serverim darbojoties. Taču datubāzei darbojoša servera momentuzņēmums ne vienmēr ir konsekvents, tāpēc iesakām atsevišķu datubāzes rezerves kopiju (dump vai WAL/binlog), ko komanda uzstāda pēc pieprasījuma.
Cik ilgi aizņem ļoti liela momentuzņēmuma (piemēram, 500 GB) atjaunošana?
Tas ir atkarīgs no datu apjoma, diska un vietas, kur kopija tiek glabāta — atjaunošana no ārējās kopijas aizņem ilgāk nekā no lokālās. Fiksētu laiku nesolām: reālistisks rādītājs rodas atjaunošanas testā, ko varam veikt kopā ar jums.
Vai rezerves kopijas ir šifrētas?
Ārējo rezerves kopiju šifrēšana ir daļa no stratēģijas, ko uzstādām pēc pieprasījuma — piemēram, kopijas, kas atstāj serveri tikai šifrētā veidā, ar atslēgām, kas glabājas atsevišķi no produkcijas. Pieprasot uzstādīšanu, pastāstiet komandai savas prasības.
Ko darīt, ja vēlos glabāšanas termiņu, kas ilgāks par 30 dienām?
Ārējo rezerves kopiju glabāšanas termiņu nosaka, kad komanda konfigurē stratēģiju, ņemot vērā jūsu vajadzības un juridiskos arhivēšanas pienākumus. Krātuve ilgākam glabāšanas termiņam tiek saskaņota ar komandu; paketes atradīsit cenu lapā.
Vai varu lejupielādēt momentuzņēmumu lokāli?
VPS un veltītajos serveros jums ir root piekļuve, un datus kopējat ar sev ērtiem rīkiem (rsync, tar). Komanda no DevOps stundām var arī uzstādīt automatizētu kopēšanu uz ārēju krātuvi, piemēram, AWS S3, Google Cloud Storage vai Azure Blob.
Jūsu dati ir pārāk vērtīgi, lai tos atstātu nejaušības ziņā
cPanel iekļauj ikdienas rezerves kopiju, un VPS iekļauj momentuzņēmumus. Veltītajos serveros komanda izveido rezerves kopēšanas stratēģiju no iekļautajām DevOps stundām. Sīkāku informāciju skatiet cenās.
Skatīt paketes →