Una notificació de backup correcte demostra que s’ha executat un procés, no que el web es pugui recuperar. Una prova real reconstrueix el lloc aïlladament, mesura el treball i registra defectes abans que una emergència els converteixi en urgents.
Defineix l’objectiu de recuperació
Tria la data exacta i especifica què ha de tornar: fitxers, base, uploads, configuració i dependències externes. Defineix un temps objectiu i els recorreguts crítics del negoci.
No utilitzis producció com a destí. Prepara un hostname de staging restringit o un entorn local no indexable.
Inventaria el conjunt
Llista arxius, SQL i volums multipart amb mida i data. Confirma que les claus de xifratge, credencials d’emmagatzematge i programari de restauració estan disponibles per a persones autoritzades.
sha256sum wordpress-files.tar.gz wordpress.sql.gzEl hash detecta danys en transferir, però no demostra que el contingut sigui complet.
Prepara un destí aïllat
Utilitza un document root i una base buits. Iguala inicialment PHP i extensions, amb prou disc, inodes i quota MySQL. Bloqueja l’accés públic i el correu transaccional sortint.
Afegeix noindex com a segona precaució, no com a única barrera per a una còpia amb dades personals. Restringeix també l’accés mitjançant autenticació.
Restaura sense dependre de l’origen
Actua com si producció no estigués disponible. Baixa des de la ubicació documentada, extreu i importa utilitzant el procediment desat.
Registra les ordres, el temps i els errors. Si cal una contrasenya o llicència no documentada, has trobat un defecte de recuperació encara que algú l’acabi localitzant.
Reconfigura l’entorn amb seguretat
Crea credencials de staging i ajusta wp-config.php. Substitueix dominis amb una eina compatible amb serialització. Desactiva pagaments, CRM, webhooks i SMTP reals per no contactar clients.
Revisa rutes absolutes i ajustos propis del servidor. Regenera memòries cau només quan les dades d’origen siguin correctes.
Verifica la integritat de les dades
Compara taules, files seleccionades, últimes entrades i registres de negoci amb l’hora prevista. Obre mitjans antics i recents i comprova que existeix el fitxer, no només la referència.
Revisa usuaris i rols sense exposar contrasenyes. No enviïs mai per correu una llista d’usuaris restaurada.
Exercita les funcions de WordPress
Prova inici de sessió, generació de restabliment sense lliurament, desament de l’editor, pujada, enllaços permanents, cerca, REST i cron. Per a formularis o comerç, utilitza endpoints sandbox i registres clarament marcats.
Revisa logs PHP, web i WordPress. Una portada visualment correcta pot amagar processos en segon pla fallits.
Mesura el rendiment de recuperació
Registra el temps per obtenir accés, baixar, restaurar, configurar i validar. Anota passos manuals i la demora més gran. Compara-ho amb els objectius de temps i punt de recuperació.
Si la importació domina, millora el mètode de servidor en lloc d’elevar timeouts del navegador.
Prova també les rutes de fallada
Confirma què cal fer si falta un volum, l’emmagatzematge rebutja l’accés o el destí no té espai. Simula-ho amb còpies de prova, mai danyant l’únic conjunt.
El procediment ha d’indicar quan aturar-se, qui autoritza una altra data i com preservar l’error. Així una decisió improvisada es converteix en una branca controlada.
Neteja la prova responsablement
Desa l’informe no secret i elimina l’entorn i els arxius temporals segons la política. Revoca credencials i confirma que DNS i regles d’accés ja no exposen dades.
Conserva la còpia original fins que caduqui la retenció.
Repeteix amb una freqüència útil
Prova després de canvis importants d’allotjament, PHP, eina o arquitectura i periòdicament. Rota les dates per no seleccionar sempre la mateixa còpia coneguda.
El manteniment recurrent ha de seguir l’èxit, la durada i els defectes pendents. El resultat és evidència de recuperació, no un altre panell verd.