Înainte de a începe
- Un inventar complet al serviciului și permisiunea de a manipula datele sale de rezervă.
- Un set de backup selectat, marcajul său temporal, versiunile software și accesul autorizat la secretele de recuperare.
- O țintă separată cu suficient spațiu și controale de acces pentru informațiile restaurate.
- Două conturi martor inofensive cu permisiuni diferite, plus o pagină și un atașament cunoscute.
- Un proprietar de test numit și un alt întreținător care poate examina rezultatul.
Decideți ce ar conta ca un notebook funcțional
Utilizați wiki-ul de atelier ilustrativ din inventar de servicii. Criteriile sale de succes sunt specifice: un editor poate găsi și modifica o pagină de test, un cititor poate vedea instrucțiunile permise, o carte privată de organizare rămâne ascunsă, iar o diagramă atașată se deschide. Utilizați aceste verificări ca plan de test înainte de a deschide backup-ul.
| Martor | Observație așteptată | Înregistrați în timpul exercițiului |
|---|---|---|
| Cont de cititor | Poate citi pagina de reparare permisă; nu o poate edita. | Reușit/eșuat și pagina verificată. |
| Cont de editor | Poate salva o modificare inofensivă în pagina de test desemnată. | Modificarea și revizia rezultată. |
| Carte restricționată | Indisponibilă pentru cititor prin navigare și printr-un link direct. | Cont, cale și acces observat. |
| Diagramă martor | Se deschide din pagina sa cu conținutul așteptat. | Numele fișierului și orice nepotrivire. |
| Notificare | Capturată doar în destinația de test izolată. | Destinația și numărul observat. |
Alegeți martori care existau atunci când a fost creat backup-ul selectat. O pagină nou creată nu poate dovedi că un backup mai vechi este incomplet.
Identificați setul exact de recuperare
Scrieți identificatorul backup-ului și marcajul temporal pe foaia de rezultate. Includeți configurația aplicației, datele bazei de date, atașamentele și informațiile software necesare pentru a le interpreta. Dacă timpii lor de captură diferă, investigați modul în care procedura dvs. de backup îi menține consecvenți înainte de a începe exercițiul.
Pentru un depozit restic, alegeți un snapshot explicit sau verificați cu atenție filtrele utilizate cu latest. Opțiunea sa --path selectează un snapshot; nu limitează fișierele restaurate. O restaurare poate suprascrie fișierele existente, ceea ce este un alt motiv de a utiliza o țintă goală, dedicată. Documentație restic restore.
Distingeți verificările depozitului de recuperarea aplicației. Un restic implicit check examinează structura depozitului; check --read-data citește de asemenea datele pachetelor stocate și poate consuma transfer și timp substanțiale. Niciuna nu verifică dacă un membru poate utiliza wiki-ul dvs. verificările de integritate restic.
Faceți copia de test silențioasă înainte de a începe
Țineți gazdele bazei de date de producție, căile de stocare și acreditările de ieșire în afara configurației de test. Rugați al doilea întreținător să compare fiecare destinație cu harta serviciului. Confirmați că ținta este separată înainte de orice operațiune de restaurare care scrie fișiere sau obiecte de bază de date.
- Restrângeți accesul la persoanele care desfășoară exercițiul.
- Păstrați neschimbate înregistrările DNS de producție.
- Blocați livrarea către exterior sau înlocuiți-o cu o destinație de captură aprobată.
- Dezactivați webhook-urile, integrările programate și lucrătorii de coadă până când comportamentul lor de test este definit.
- Verificați că linkurile și redirecționările browserului nu pot duce în liniște testerul înapoi la producție.
Tratați datele restaurate ca fiind la fel de sensibile ca originalul. Izolarea este o verificare operațională de demonstrat, nu o etichetă atașată unui director. Dacă nu puteți verifica destinațiile sau controalele, opriți-vă înainte de a porni aplicația.
Aduceți înapoi piesele într-o ordine deliberată
Urmați instrucțiunile de restaurare pentru metoda de instalare și versiunile din inventarul dvs. Pentru exemplul BookStack, procedura oficială acoperă o restaurare separată a bazei de date și a fișierelor, păstrând originalul APP_KEY, și ajustând URL-ul aplicației când adresa se schimbă. Configurările cu containere necesită restaurarea bazei de date înainte de a rula containerul aplicației. Secvența de restaurare BookStack și note de configurare.
- Pregătiți mediul de rulare dedicat și ținta bazei de date fără a porni traficul obișnuit al membrilor.
- Restaurați baza de date și fișierele corespunzătoare; păstrați backup-ul original neschimbat.
- Aplicați adresele mediului de test și conexiunile externe restricționate.
- Verificați proprietatea și accesul la fișierele necesare conform instrucțiunilor de instalare ale aplicației.
- Porniți serviciul cu acțiunile de ieșire încă controlate, apoi rulați martorii planificați.
Recuperarea mai întâi a versiunii înregistrate menține un exercițiu de rutină concentrat. Dacă exercițiul necesită și o schimbare de versiune, documentați separat calea sa de migrare și punctul de recuperare. Nu faceți dintr-o actualizare neplanificată remediul pentru un eșec de restaurare neexplicat.
Verificați atât ce funcționează, cât și ce rămâne interzis
Rulați verificările de cititor și editor în sesiuni de browser separate, astfel încât o sesiune de administrator să nu poată ascunde un eșec de permisiuni. Testați un atașament prin pagină și prin adresa sa directă. Căutați o expresie cunoscută, urmați un link intern și inspectați o revizie mai veche care ar trebui să existe în copia de rezervă.
Dacă o verificare eșuează, înregistrați prima diferență observabilă. O imagine lipsă sugerează o investigație diferită de o redirecționare neașteptată la autentificare sau de o conexiune interzisă la baza de date. Păstrați dovezile de eroare relevante fără a copia conținut privat sau credențiale într-o notă generală de asistență. Corectați o singură cauză identificată și repetați verificarea afectată; nu modificați permisiunile în mod larg doar pentru a face o eroare să dispară.
Testați e-mailul doar către destinația de captare aleasă. BookStack oferă o acțiune de testare a e-mailului și documentează că unele eșecuri de notificare apar în jurnale în loc de pagina utilizatorului. Examinați acele dovezi, precum și rezultatul vizibil. Verificările de e-mail BookStack și comportamentul la eșec.
Lăsați un rezultat onest pentru următoarea persoană
Service / test owner / reviewer:
Backup identifier / capture timestamp:
Application and database versions:
Isolated target / access restrictions:
Outbound actions disabled or redirected:
Test start / usable-service checkpoint / finish:
Reader / editor / private book / attachment results:
Search / links / revision / notification results:
Missing information or failed steps:
Corrective action / owner / next exercise:
Test data cleanup completed by:Introduceți orele observate numai după efectuarea lucrării și indicați ce măsoară fiecare punct de control. O singură repetiție reușită este o dovadă pentru acea copie de rezervă și procedură; nu stabilește o garanție de recuperare pentru alt eșec. Confirmați curățarea copiei de test și a mesajelor capturate conform regulilor de păstrare ale grupului. Reintroduceți elementele lipsă în inventar și utilizați exporturi de date portabile pentru a pregăti o cale separată de mutare a conținutului grupului.
Documentația din spatele acestei note
Folosiți documentația pentru versiunea pe care o rulați efectiv. Aceste exemple sunt material de planificare, nu o dovadă a unui test pe un VPS Hoszen.