Revizuit · Resurse Hosmio
Înainte de a începe
Alegeți o destinație de unică folosință și un domeniu de test scris. Confirmați accesul la codul aplicației, versiunile software necesare și materialul de backup aprobat. Păstrați ținta separată de producție, cu notificările de ieșire, sarcinile programate și scrierile externe dezactivate până când sunt testate în mod deliberat.
01
Enumerați ce trebuie mutat și ce trebuie recreat.
Includeți runtime-ul, baza de date, fișierele încărcate, configurația, sarcinile programate, certificatele, proprietatea DNS și integrările externe. Înregistrați cine controlează fiecare dependență și cum poate fi recuperat accesul dacă VPS-ul actual este indisponibil. Identificați orice caracteristică specifică furnizorului care necesită o înlocuire, nu o copiere de fișier.
Notați versiunile și extensiile așteptate. O comandă de instalare care preia orice este mai nou astăzi poate să nu recreeze aplicația pe care o operați. Faceți referire la stocarea protejată a secretelor pentru credențiale; un plan de recuperare ar trebui să explice cum o persoană autorizată le recuperează fără a pune secretele în planul însuși.
02
Alegeți o metodă de export și restaurare conștientă de date.
Pentru PostgreSQL, un export logic cu pg_dump acoperă o singură bază de date, în timp ce obiectele globale, cum ar fi rolurile, necesită tratare separată. Instrumentul refuză să execute dump-ul unui server de la o versiune majoră mai nouă decât cea suportată de client. Documentația oficială avertizează, de asemenea, împotriva tratării pg_dump ca o strategie universală de backup regulat în producție. PostgreSQL: pg_dump ↗
Alegeți metoda adecvată aplicației și nevoilor de recuperare împreună cu operatorul. Înregistrați ce omite exportul și modul în care fișierele sunt menținute consecvente cu referințele bazei de date. O comandă care se încheie cu succes este o primă verificare utilă, nu dovada că o aplicație completă a fost păstrată.
03
Restaurați într-o țintă explicit separată.
Inspectați arhiva și destinația înainte de restaurare. Restaurarea arhivelor PostgreSQL utilizează pg_restore; opțiunile care curăță obiectele existente pot elimina date, iar comportamentul său implicit poate continua după erori SQL. Planificați gestionarea erorilor și inspectați rezultatul în loc să presupuneți că fiecare obiect a fost restaurat. PostgreSQL: pg_restore ↗ Nu rulați un tutorial pe baza de date de producție doar pentru că numele îi este familiar.
Pentru backup-urile de fișiere, selectați instantaneul dorit și o destinație de test goală. Restic documentează că restaurarea poate suprascrie fișierele existente; o suprascriere întreruptă poate lăsa un rezultat parțial. restic: restaurare din backup ↗ Înregistrați instantaneul sursă și calea țintă în nota exercițiului. Acestea sunt linii directoare de selectare a metodei, nu comenzi executate sau verificate pe un VPS Hosmio.
04
Verificați sarcinile utilizatorilor și efectele secundare ascunse.
| Verificați | Dovezi de păstrat | Rezultat |
|---|---|---|
| Aplicația pornește cu versiunile documentate | Inventarul versiunilor și rezultatul pornirii | Încă netestat |
| Înregistrările și fișierele reprezentative sunt conforme | Verificări sintetice ale înregistrărilor și atașamentelor | Încă netestat |
| Permisiunile se comportă corect | Două roluri de test și accesul așteptat | Încă netestat |
| Sarcinile nu trimit activitate externă duplicată | Acțiuni de ieșire dezactivate sau test controlat | Încă netestat |
| Operatorul de înlocuire poate urma notele | Parcurgere independentă și lacune | Încă netestat |
Utilizați conturi sintetice și înregistrări de test inofensive oriunde este posibil. Verificați limitele de acces, precum și citirile reușite. O aplicație care pornește dar acordă permisiuni greșite nu este o recuperare reușită. Păstrați verificările eșuate în registru cu un responsabil pentru remediere.
05
Planificați momentul în care noile scrieri schimbă decizia.
O repetiție ar trebui să informeze secvența viitoarei mutări: pasul final de consistență, verificările destinației, comutarea traficului, decizia de acceptare și retragerea serviciului vechi. Decideți cine poate opri sau inversa operațiunea. Dacă destinația a acceptat noi scrieri, trimiterea utilizatorilor înapoi la o copie veche poate pierde sau diviza acele scrieri; revenirea necesită un plan de date, nu doar o schimbare DNS.
Permiteți suprapunerea în buget. Pot fi necesare un al doilea server, stocare independentă, costuri de trafic, licențe și timpul operatorului. Nu presupuneți că un furnizor proratează VPS-ul sau că fondurile prepay sunt rambursabile. Prețurile publicate pe perioadă ale Hosmio descriu termeni de plată anticipată; ele nu definesc un serviciu de migrare sau rambursare.
06
Lăsați dovezi pe care le poate folosi un alt operator.
Înregistrați data exercițiului, versiunile, identificatorii copiilor, ținta, efortul depus și rezultatele numai după ce exercițiul este efectiv realizat. Până atunci, utilizați „planificat” sau „netestat”. Păstrați fișa de acceptare împreună cu notele de recuperare și listați dependențele care încă împiedică o reconstrucție independentă.
Dacă repetiția eșuează, clasificați lacuna: date lipsă, software incompatibil, credențiale indisponibile, o dependență externă sau o procedură neclară. Rezolvați cea mai mică problemă blocantă, apoi repetați verificarea afectată. Nu declarați aplicația portabilă cât timp o sarcină critică rămâne netestată.
Conectați planul la responsabilități operaționale numite și procesul de aprobare a modificărilor al clientului. Rezultatul vizat este o capacitate demonstrată de a recupera într-un domeniu documentat, nu o promisiune de întrerupere zero sau o migrare livrată automat.