Hi ha una frase incòmoda que circula entre administradors de sistemes: una còpia de seguretat que no s’ha restaurat mai no és una còpia de seguretat, és una esperança. Sona a exageració fins que et toca comprovar-ho el dia dolent.
Per què falla justament quan la necessites
El problema no és que les còpies no es facin. Gairebé sempre es fan. El problema és que fer la còpia i poder recuperar-la són dues coses diferents, i només la primera es verifica sola.
Les fallades que apareixen únicament al restaurar són sempre les mateixes: la còpia es completava però el fitxer estava corrupte; el bolcat de la base de dades es feia amb la màquina en marxa i va quedar inconsistent; el sistema copiava una carpeta que ja no era la de dades perquè l’aplicació va canviar de ruta fa mesos; la còpia era correcta però ningú sabia el procediment i es van perdre sis hores improvisant.
Cap d’aquests problemes dona la cara en un informe de còpia correcta. Tots apareixen la primera vegada que restaures.
Què ha de demostrar una prova de veritat
Una prova de restauració útil no és obrir la còpia i veure que hi ha fitxers dins. Ha de respondre quatre preguntes amb dades:
- Es recupera el sistema complet? Arrencat, no només descomprimit.
- Quant triga? Cronometrat. Aquest número és el teu temps de recuperació real, i serveix per posar expectatives abans d’una crisi, no durant.
- Les dades són consistents? Les bases de dades, sobretot. Que arrenquin i que responguin a una consulta.
- Està escrit el procediment? Perquè el dia que calgui pot no estar disponible qui el sap de memòria.
Com fer-la sense risc
La regla d’or: restaura sempre a un destí nou, mai sobre l’original. Un identificador diferent, i amb la interfície de xarxa desconnectada.
Aquest últim detall importa més del que sembla. Una restauració conserva la configuració de xarxa original, així que si l’aixeques connectada tindràs dues màquines barallant-se per la mateixa IP i trencaràs el servei en producció mentre feies una prova de seguretat. Aixeca-la amb la xarxa desconnectada, verifica des de la consola, i destrueix-la al acabar.
Amb quina freqüència
Trimestral és un bon punt de partida per a la majoria. I sempre, obligatòriament, després d’un canvi rellevant: una migració, una actualització major, un canvi en l’estructura de dades o en la política de còpies. Els canvis són precisament el que trenca les còpies sense avisar.
Un exemple amb números
La nostra última prova documentada, feta sobre un servidor real i no sobre un cas de laboratori: restauració completa des del nostre centre de dades principal en 33 segons, i des del segon centre de dades en 58 segons, en les dues ocasions sobre un node físic diferent a l’original.
L’interessant d’aquests números no és que siguin baixos. És que existeixen: quan un client ens pregunta quant triga una recuperació, la resposta no és una estimació, és una mesura.
Què hauries de demanar al teu proveïdor
Si tens còpies contractades amb algú, la pregunta és directa: quan va ser l’última restauració real que vau fer, i quant va trigar? Un proveïdor que ho prova té la dada a mà. Un que no, improvisa una resposta genèrica.
Com ho fem
A les nostres còpies de seguretat documentem les proves de restauració amb data, origen, destí i temps mesurats. I al nivell gestionat, fem la prova periòdica per tu i t’entreguem l’informe. Tot dins dels nostres dos centres de dades a Andorra.