Copia de seguridad y restauración de VPS: cifrada, fuera de las instalaciones y probada de verdad

Las instantáneas no son copias de seguridad — y quieres tener ambas cosas

Una instantánea es una copia de un volumen en un punto concreto del tiempo, que vive en el mismo sistema de almacenamiento que el volumen que copió. Eso no es una crítica, es una descripción, y explica con precisión en qué es excelente una instantánea y qué es lo que no puede hacer. Todos los planes aquí incluyen instantáneas cada hora con siete días de retención, restaurar una tarda unos treinta segundos, y son la respuesta correcta al incidente más habitual con diferencia en la operación de servidores: editaste un archivo de configuración a las cuatro de la tarde y el servicio no ha vuelto a arrancar desde entonces. Para ese tipo de fallo nada más se le acerca — es más rápido que cualquier herramienta de copia de seguridad, ya está en marcha, y no cuesta nada extra.

Lo que una instantánea no puede hacer es sobrevivir a aquello sobre lo que está almacenada. Comparte destino con el volumen, el host, el hipervisor y, en la mayoría de los diseños, la cuenta. Si la máquina es incautada, si la cuenta se cierra, si al centro de datos le va muy mal un día, las instantáneas desaparecen con él — son una copia de los datos, no una copia independiente. La distinción no es académica en un proveedor que deliberadamente no puede identificarte: no hay ninguna vía de soporte que reconstruya tu servidor a partir de los registros de otra persona, ningún flujo de recuperación vinculado a un número de teléfono, y ningún historial de facturación con tu nombre legal asociado. Lo que tomaste es lo que tienes.

Tampoco una ventana de siete días ayuda con los dos fallos lentos. El archivo que borraste hace cinco semanas ha desaparecido de todas las instantáneas mucho antes de que te des cuenta. La corrupción silenciosa — una aplicación que falla y escribe datos sutilmente incorrectos, una migración defectuosa, un cliente de sincronización que propaga fielmente un error — a menudo se descubre un mes después, momento en el que ya todas las copias conservadas contienen la corrupción. Las copias de seguridad con una retención más larga y un historial real son las que cubren esos casos, y los cubren precisamente porque no son espejos continuos del estado actual.

El marco de referencia que merece la pena interiorizar aquí es antiguo y sigue siendo válido. La regla 3-2-1 pide tres copias de los datos, en dos tipos de almacenamiento distintos, con una de ellas fuera de las instalaciones. El añadido moderno suma dos cifras más — 3-2-1-1-0 — donde el uno extra es una copia inmutable o desconectada, y el cero es el número de errores en tu última verificación. Las cifras son una regla mnemotécnica más que un estándar, pero codifican las tres propiedades que realmente importan: independencia, inmutabilidad, y la prueba de que la cosa funciona. Las instantáneas cada hora te dan una de las tres.

Lee esa tabla como un argumento a favor de usar ambas cosas en lugar de elegir entre ellas. Las instantáneas se ocupan de la frecuencia y la velocidad; las copias de seguridad se ocupan de la independencia y el historial. Tienen costes distintos, fallan de maneras que no coinciden entre sí, y la combinación resulta mucho más sólida que duplicar cualquiera de las dos por separado.

Las dos cifras que determinan todo lo demás

Antes de instalar ninguna herramienta, anota dos cifras. El objetivo de punto de recuperación (RPO) es cuántos datos puedes permitirte perder, medido en tiempo — si la última copia utilizable tiene seis horas de antigüedad, tu RPO es de seis horas, y las seis horas de trabajo intermedias se han perdido. El objetivo de tiempo de recuperación (RTO) es cuánto tiempo puedes permitirte estar sin servicio mientras reconstruyes. Todo lo que viene después — la planificación, el método, dónde vive la segunda copia, cuánto gastas — se deriva de esas dos cifras, y elegir el software antes de elegirlas es la forma en que la gente acaba con una respuesta elaborada a una pregunta que nadie hizo.

Preguntada así, sin pensarlo mucho, la mayoría de la gente dice cero y cero. Eso no es un presupuesto, es un deseo, y tiene un precio que merece la pena decir sin rodeos: un RPO cercano a cero implica replicación continua en lugar de copias programadas, y un RTO cercano a cero implica una segunda máquina en caliente ya en marcha. Ambas cosas son viables y ambas duplican aproximadamente el coste operativo de aquello que estás protegiendo. Para la inmensa mayoría de las cargas de trabajo autoalojadas, las respuestas honestas están entre una hora y un día para el punto de recuperación, y unas pocas horas para el tiempo de recuperación, algo que cubre sobradamente una copia de seguridad cifrada programada y una reconstrucción documentada.

Las cifras también varían según el conjunto de datos dentro de la misma máquina, y ese detalle es justo lo que las hace útiles. El correo es el ejemplo más claro: un mensaje que llegó hace veinte minutos no existe en ningún otro sitio, no se puede regenerar, y quien lo envió no tiene ni idea de que hay que reenviarlo — así que un servidor de correo necesita un punto de recuperación medido en minutos, aunque el software en sí se reinstale en una tarde. Un nodo de Bitcoin invierte esto por completo: los datos de la cadena son varios cientos de gigabytes que cualquier par de la red te reenviará encantado, así que hacerles una copia de seguridad es en gran medida un desperdicio de disco, mientras que el archivo del monedero de al lado es irrecuperable y merece protegerse como una clave privada, porque eso es exactamente lo que es.

Esa última fila merece decirse en voz alta, porque una guía sobre copias de seguridad tiene un incentivo evidente para no hacerlo. Algunas máquinas no necesitan ninguna. Un agente de compilación cuyo estado completo procede de un repositorio git, un sandbox desechable, un proxy inverso sin estado cuya configuración vive en un control de versiones — para estos casos, las instantáneas cada hora incluidas con el plan son una respuesta completa y defendible, y la cantidad correcta de ingeniería de copias de seguridad es ninguna. Saber cuáles de tus servidores están en esa categoría vale más que hacerles a todos una copia de seguridad mal hecha.

Qué copiar — y el montón, mucho más grande, que deberías omitir

El instinto es crear una imagen de todo el disco, y en una máquina virtual alquilada ese instinto es erróneo. El sistema operativo es desechable: aquí una instancia nueva se aprovisiona en una mediana de cuarenta y un segundos, y reinstalar paquetes desde un espejo de la distribución es más rápido y más fiable que restaurarlos desde tu propia copia. Lo que no es desechable es un conjunto sorprendentemente pequeño, y la disciplina de nombrar ese conjunto de forma explícita es la mayor parte del trabajo — una copia de seguridad que puedes describir en un párrafo es una que puedes verificar, mientras que una imagen de disco completo es algo sobre lo que solo puedes tener esperanzas.

El conjunto insustituible normalmente son cuatro cosas. Primero, los datos de la aplicación: el maildir, el directorio de datos, el almacén de medios, la carpeta de subidas. Segundo, las bases de datos, que necesitan un tratamiento propio y tienen la siguiente sección dedicada. Tercero, los secretos — y esta es la categoría que la gente olvida hasta que le sale cara. Las claves privadas TLS y la clave de cuenta ACME, las claves de host SSH si prefieres no tener que volver a confiar en la huella digital en cada cliente, la clave de firma DKIM sin la cual tu correo empieza a fallar la autenticación, las claves privadas de WireGuard y, sobre todo, la clave privada del servicio onion, que es la dirección .onion: piérdela y la dirección desaparece para siempre, sin ningún registro en ningún sitio al que apelar. Cuarto, el puñado de archivos bajo /etc que de verdad modificaste, además de las unidades de systemd, las entradas de cron y el conjunto de reglas del cortafuegos que hacen que la máquina se comporte como lo hace.

El montón que hay que omitir es mucho más grande y, una vez dicho, casi obvio. Los pseudo-sistemas de archivos como /proc, /sys y /dev son vistas del kernel, no datos. Las cachés de paquetes, las imágenes de contenedores, los entornos virtuales y los directorios de dependencias se pueden volver a derivar en segundos a partir de un lockfile. Los registros que superan tu política de retención son ruido que deduplica mal e infla cada ejecución posterior. Y los grandes conjuntos de datos resincronizables — el estado de la blockchain, un espejo público, una biblioteca de medios que puedes volver a extraer — merecen una decisión explícita en lugar de una por defecto: hacer copia de seguridad de trescientos gigabytes de datos de cadena cuesta dinero real cada mes para evitar una resincronización que podrías ejecutar gratis mientras el servicio está degradado pero funcional.

La parte en la que casi todo el mundo invierte de menos es la respuesta a «¿restaurar hacia dónde?». Los datos sin un destino no son una recuperación. Si la forma en que se construyó tu servidor existe solo en tu memoria y en un historial de shell que ya has perdido, tu tiempo de recuperación no tiene límite, por muy bueno que sea el repositorio. La solución es barata y aburrida: guarda los pasos de aprovisionamiento como un script o un runbook en texto plano, ponlo dentro del repositorio de copias de seguridad para que se restaure junto con los datos, y actualízalo cada vez que cambies la máquina. Incluso un centenar de líneas de notas — paquetes, versiones, ubicaciones de los archivos de configuración, registros DNS, el orden en que deben arrancar los servicios — convierte una semana mala en una tarde mala.

Un matiz que merece la pena señalar para quienquiera que use cifrado de disco completo: la cabecera LUKS y sus ranuras de claves también forman parte de tu conjunto insustituible. Una cabecera corrupta convierte un disco perfectamente intacto en ruido aleatorio, la cabecera pesa unos pocos megabytes, y hacerle una copia de seguridad no cuesta nada. Guárdala con el mismo cuidado que la frase de contraseña — quien tenga ambas cosas tiene el disco.

Bases de datos: el archivo que copias no es la base de datos

Esta es, con diferencia, la forma más habitual en que una copia de seguridad por lo demás competente resulta ser inútil. Un motor de base de datos mantiene su estado en memoria, en un write-ahead log o redo log, y en archivos de datos que se están modificando continuamente. Copiar esos archivos mientras el motor está en marcha los captura en instantes distintos — la página cuatro de una tabla de antes de una transacción, la página cinco de después — y el resultado es un conjunto de archivos que, por separado, están intactos y que, en conjunto, son inconsistentes. Lo cruel es que ese tipo de copia normalmente se restaura. Arranca, responde a las consultas, y el daño sale a la luz semanas después en forma de un índice corrupto o una fila que viola una restricción que el motor juraba estar haciendo cumplir. Una copia de seguridad que falla de forma ruidosa es muchísimo mejor que una que falla en silencio.

El enfoque correcto depende del motor y está bien documentado en cada caso. Para MariaDB y MySQL, un volcado lógico realizado dentro de una única transacción coherente es adecuado para cualquier cosa hasta unas pocas decenas de gigabytes; a partir de ahí, Mariabackup realiza una copia física en caliente mientras el servidor está en marcha. Para PostgreSQL, pg_dump te da una instantánea lógica portable, y pg_basebackup combinado con write-ahead logs archivados te da recuperación a un punto en el tiempo — la capacidad de restaurar hasta las 14:32 en lugar de hasta el momento en que se ejecutó por casualidad el último volcado. Para SQLite, usa la copia de seguridad en línea integrada o VACUUM INTO; usar cp sobre un archivo de base de datos en marcha es exactamente el error descrito antes, y SQLite es el motor en el que la gente lo comete más a menudo porque parece un archivo normal.

La coherencia entre la base de datos y los archivos que describe es la segunda mitad del problema, y es la mitad que muerde específicamente al software de sincronización de archivos y a los foros. La base de datos dice que existe un archivo en una ruta; el sistema de archivos es donde viven los bytes; si vuelcas la base de datos a las 02:00 y copias el directorio de datos a las 02:40, todo lo creado en ese intervalo existe como bytes sin fila, o como fila sin bytes. Las aplicaciones que ofrecen un modo de mantenimiento — Nextcloud es el caso obvio — resuelven esto rechazando brevemente las escrituras mientras se capturan ambas cosas. Cuando eso no es aceptable, una instantánea del sistema de archivos o del volumen tomada en un único instante te da un par coherente del que copiar con calma, que es el mismo truco que usan las instantáneas cada hora.

Hay un pequeño detalle operativo que se rentabiliza de inmediato: escribe los volcados sin comprimir y deja que la herramienta de copia de seguridad se encargue de la compresión. Tanto restic como borg deduplican dividiendo los datos en chunks definidos por su contenido, así que dos volcados hechos con un día de diferencia comparten la inmensa mayoría de sus chunks, y el segundo cuesta casi nada almacenar. Si comprimes el volcado primero, un solo byte que cambie cerca del principio se propaga en cascada por todo el flujo comprimido, ningún chunk coincide con nada, y cada ejecución almacena una copia completa. Los equipos se encuentran habitualmente con que su repositorio crece el tamaño completo de la base de datos cada día por esta misma razón — la solución es eliminar una tubería de un script de shell.

Por último, decide de forma deliberada si necesitas recuperación a un punto en el tiempo, porque es la respuesta a un fallo que el volcado diario no puede resolver. Si alguien ejecuta una consulta destructiva a las 14:32 y lo descubres a las 17:00, restaurar el volcado de anoche te hace perder un día laboral entero. El archivado continuo, en cambio, reproduce el registro hasta las 14:31. Cuesta más almacenamiento y bastante más complejidad operativa, así que no es la opción por defecto — pero en cualquier caso en el que una persona con acceso de escritura pueda destruir datos más rápido de lo que puedes darte cuenta, es la diferencia entre un incidente y una catástrofe.

Cifra antes de que salga: restic, borg y la clave que no debes perder

La propiedad que hace posible todo lo demás en esta guía es el cifrado del lado del cliente: los datos se cifran en la máquina que los produjo, antes de que un solo byte cruce la red, usando una clave que el destino nunca llega a ver. Esa única decisión de diseño convierte el destino de la copia de seguridad en almacenamiento no confiable, y el almacenamiento no confiable puede estar en cualquier lugar — un servidor barato en otro país, un almacén de objetos, el NAS de un amigo — sin que ninguno de ellos esté en posición de leer tus datos. Los proveedores que cifran del lado del servidor te protegen de un conjunto de amenazas distinto y mucho más limitado, y la diferencia importa sobre todo precisamente en las situaciones para las que compras alojamiento offshore para sobrevivir.

Restic y Borg hacen esto correctamente, y la elección entre ambos es realmente reñida. Restic es un único binario estático sin dependencias, habla de forma nativa una larga lista de backends — SFTP, almacenamiento de objetos compatible con S3, rutas locales simples — y es el más fácil de los dos de ejecutar desde un contenedor o una imagen mínima. Borg es la herramienta más antigua y, en algunos aspectos, más quirúrgica, con opciones de compresión más potentes, un excelente soporte de append-only en el lado del servidor, y un formato de repositorio que a mucha gente le resulta más fácil de entender; requiere tener borg instalado en ambos extremos al pasar por SSH, una pequeña restricción que a veces termina siendo decisiva.

Elijas lo que elijas, la frase de contraseña lo es todo a partir de ahora, y merece el mismo trato que le darías a la semilla de un monedero. No debe vivir únicamente en la máquina que protege — una frase de contraseña guardada junto a los datos que cifra no te protege absolutamente de nada, porque cualquier escenario que se lleve el servidor se lleva la clave con él. Guárdala en un gestor de contraseñas en otro dispositivo, o en papel en otro edificio, e idealmente en ambos. Borg te permite exportar la clave del repositorio a un archivo aparte, restic permite que un repositorio tenga varias claves independientes, y cualquiera de los dos mecanismos te da una segunda vía de acceso que no depende de recordar una cadena de texto. No hay recuperación, ni enlace de restablecimiento, ni ticket de soporte que revierta esto: un repositorio cifrado sin su clave es indistinguible de datos aleatorios, que es precisamente el objetivo.

Merece la pena explicar con claridad por qué un simple rsync hacia otro servidor no es un sustituto, ya que es lo primero a lo que la gente recurre. Rsync produce un espejo, y un espejo no tiene historial: borra un archivo hoy y la ejecución de esta noche lo borrará fielmente también allí. No tiene deduplicación, así que conservar treinta días significa treinta copias, a menos que te las ingenies con enlaces duros. No tiene cifrado en reposo integrado, así que el destino lee todo lo que le envías. Y no tiene más verificación que releer el origen. Es un excelente transporte y una mala copia de seguridad, y la diferencia se nota el día que necesitas la versión de hace tres semanas.

Append-only, o es una copia y no una copia de seguridad

Este es el escenario que decide la arquitectura. Alguien consigue root en tu servidor — a través de una aplicación sin parchear, un token filtrado, una dependencia que se ha vuelto hostil. Ahora está dentro de una máquina que tiene credenciales válidas para su propio destino de copias de seguridad, porque así es como funcionan las copias de seguridad programadas. Todo lo que esa máquina puede borrar, esa persona puede borrarlo, y borrar las copias de seguridad no es un detalle secundario en una intrusión moderna, es el primer paso. Lo mismo se aplica sin que exista un adversario: un script bienintencionado con una variable mal puesta, ejecutado como root, es perfectamente capaz de podar un repositorio hasta dejarlo en nada.

El control que cierra esto es el cumplimiento de append-only en el lado receptor. Configurado así, el cliente puede crear nuevos snapshots y no puede eliminar ni reescribir los antiguos — la restricción la impone el proceso en el host de copias de seguridad, no la buena voluntad del cliente. Borg lo implementa con borg serve --append-only, anclado a la clave en el authorized_keys del destino, de modo que el cliente no puede pedir nada más. Restic tiene el mismo planteamiento a través de rest-server con --append-only. En almacenamiento de objetos, el equivalente es el versionado más una política de retención con object lock, que logra el mismo resultado por un mecanismo diferente.

Merece la pena dejar exactamente bien ajustada la configuración SSH que sostiene esto, porque es la línea estructural. En el authorized_keys del usuario de copias de seguridad, antepón a la clave del cliente un comando forzado y las restricciones que documenta el manual de sshd: command="borg serve --append-only --restrict-to-path /srv/backups/web01",restrict. Esa única línea significa que una clave robada al cliente no puede abrir una shell, no puede redirigir un puerto, no puede tocar el repositorio de otro host, y no puede borrar nada. Da a cada cliente su propia clave y su propia ruta.

Lo cual plantea la pregunta obvia: si el cliente nunca puede borrar, ¿qué elimina los snapshots antiguos? La poda ocurre en otro sitio, según un calendario, con una credencial que la máquina protegida nunca ha tenido. En la práctica eso significa que el host de copias de seguridad poda sus propios repositorios desde un cron local, o que una tercera máquina pequeña guarda la clave privilegiada y ejecuta la retención semanalmente. Borg tiene aquí una particularidad conocida — un repositorio append-only necesita que su compactación se ejecute en el lado del servidor y no por parte del cliente — y tratar al host de copias de seguridad como el propietario de la retención resuelve eso limpiamente. El principio se generaliza: la máquina que escribe las copias de seguridad nunca debería ser la máquina que puede destruirlas.

La retención en sí es una cuestión de política con una respuesta convencional que funciona: conserva los últimos diarios, cuatro o cinco semanales, y de seis a doce mensuales. Ambas herramientas expresan esto de forma declarativa, así que indicas la forma que quieres y dejas que la herramienta decida qué snapshots la cumplen. Los mensuales son los que detectan la corrupción lenta, y también son los primeros que la gente recorta cuando el repositorio crece — lo cual es exactamente al revés, ya que un mensual comprimido y deduplicado de un conjunto de datos que apenas cambia cuesta casi nada.

Adónde va la segunda copia cuando nadie puede identificarte

Lo de «fuera de sitio» carga con gran parte del peso en la regla 3-2-1, y en un proveedor sin KYC significa algo más concreto que «otro edificio». Significa una copia cuya supervivencia no depende de la misma empresa, la misma cuenta, la misma relación de pago ni la misma jurisdicción legal que el original. Dos servidores en una sola cuenta son dos servidores con un único destino, por muy separados que estén los centros de datos: una cuenta cerrada por cualquier motivo se lleva a ambos, y un requerimiento legal notificado a una entidad alcanza todo lo que esa entidad posee. La independencia es una propiedad de la relación, no solo de la geografía.

La versión práctica de esto es más fácil de lo que parece, porque el mismo panel ya ofrece cuatro jurisdicciones. Una instancia de producción en los Países Bajos con su repositorio enviado a un plan Starter en Islandia cuesta $8.50 al mes y pone tu recuperación fuera del alcance de cualquier proceso nacional aislado — y como las jurisdicciones difieren en lo que realmente resisten, la combinación merece un momento de reflexión y no un cara o cruz. Como el repositorio se cifra antes de salir del origen, el host de copias de seguridad no es de confianza por diseño: lo que compras con la segunda ubicación es disponibilidad y distancia legal, no confidencialidad. Confidencialidad ya la tienes.

Para una tercera copia genuinamente independiente, la arquitectura más sólida invierte el sentido de la conexión. En lugar de que el servidor envíe los datos a un destino para el que tiene credenciales, una máquina que tú controlas — un equipo en casa, un NAS, un portátil que se despierta según un horario — extrae los datos del servidor. La máquina de producción entonces no tiene ninguna credencial hacia ningún destino de copias de seguridad, lo que hace que el escenario de compromiso de la sección anterior sea estructuralmente imposible y no solo mitigado. Te cuesta tener una máquina que debe estar accesible o despierta según ese horario, razón por la cual complementa una copia fuera de sitio enviada de forma activa, en lugar de sustituirla.

Merece la pena exponer sin adornos dos limitaciones propias de este tipo de hosting. No existe recuperación de cuenta: ni documento de identidad que presentar, ni número de teléfono para recibir un código, ni representante que pueda confirmar que eres tú. Es la misma propiedad por la que pagas al registrarte, y se aplica simétricamente — lo que convierte a la frase de contraseña y al runbook en elementos estructurales de un modo en que sencillamente no lo son en un proveedor convencional. Y si hay que pagar por el destino de las copias de seguridad, también hay que pagarlo de forma anónima, o la segunda copia reintroduce silenciosamente el vínculo de identidad que la primera estaba diseñada para evitar. Pagar ambas máquinas desde el mismo monedero de criptomonedas no supone ningún problema; pagar la copia de seguridad con una tarjeta es una decisión, no un descuido.

El simulacro, y cómo te enteras de que ha dejado de funcionar

Los trabajos de copias de seguridad no suelen fallar de forma dramática. Fallan de forma gradual: un patrón de exclusión que se amplía durante una limpieza, una credencial rotada solo en un lado, un disco que se llena en el destino, una entrada de cron perdida en una actualización de la distribución. En todos esos casos la máquina sigue funcionando, no salta ninguna alerta, y el repositorio deja de crecer silenciosamente. El diseño que detecta esto no es «alertar ante el fallo» — un trabajo que ya no se ejecuta no puede informar de su propio fallo — sino alertar ante la ausencia de éxito. Haz que cada ejecución exitosa haga ping a un endpoint dead-man's-switch, y que ese endpoint dé la voz de alarma cuando el ping no llegue a tiempo. Son diez minutos de configuración, y es la diferencia entre darte cuenta en un día o darte cuenta durante una restauración.

La comprobación de integridad es la segunda mitad. Ambas herramientas pueden verificar que los metadatos del repositorio son coherentes, y, de forma más útil, que los fragmentos almacenados realmente se descifran y coinciden con sus hashes. Leerlo todo sale caro en ancho de banda, así que ambas ofrecen una forma parcial — restic comprueba un porcentaje de los datos en cada ejecución, borg verifica datos bajo demanda — y una cadencia razonable es una comprobación completa de metadatos semanal y una comprobación parcial de datos mensual, calculada de modo que se complete un pase entero a lo largo de un trimestre. El almacenamiento sí se degrada, y la razón de comprobarlo es enterarte mientras todavía tienes otra copia.

Nada de esto demuestra que puedas restaurar. Esa prueba tiene exactamente una fuente, que es restaurar de verdad. Despliega una instancia nueva — el plan más pequeño cuesta $8.50 y la destruirás en menos de una hora — restaura el repositorio en ella, y luego haz la parte que la gente se salta: arranca la aplicación y mira datos reales. Inicia sesión. Abre un documento del mes pasado. Envía un mensaje de prueba a través del servidor de correo. Consulta una tabla que debería tener las filas de ayer. Que los archivos existan no es la prueba; que el servicio funcione sobre ellos sí lo es. Haz esto la primera vez que configures la copia de seguridad, y luego con una periodicidad de calendario que realmente respetes, porque el simulacro también valida el runbook, y el runbook se queda desactualizado más rápido que los datos.

El runbook merece su propio párrafo porque es lo más barato de toda esta lista y lo que más a menudo falta. Apunta, en orden: dónde vive el repositorio y cómo llegar hasta él, dónde se guarda la frase de contraseña, cómo aprovisionar una máquina de repuesto, qué paquetes y versiones instalar, qué restaurar y en qué orden, qué registros DNS cambiar, y cómo confirmar que ha funcionado. Guárdalo fuera de la máquina que describe — en el propio repositorio, en un gestor de contraseñas, en papel — y da por hecho que la persona que lo lea estará cansada, trabajando a una hora intempestiva, y puede que no seas tú. Esa última suposición es lo que convierte un conjunto de notas en algo que un compañero o un familiar puede ejecutar.

En conjunto, todo el diseño no tiene nada de extraordinario, y esa es su virtud: los snapshots por horas que tu plan ya incluye para los accidentes de los últimos días, un repositorio cifrado enviado cada noche a una segunda jurisdicción donde no se puede borrar, una frase de contraseña en algún lugar que el servidor nunca ha visto, un ping que se queja cuando el trabajo se queda callado, y un ensayo marcado en el calendario. Nada de esa lista es difícil, la mayor parte es cosa de una tarde, y el conjunto cuesta al mes menos que el café que comprarías mientras reconstruyes todo desde cero. Si estás montando esto ahora mismo, la segunda máquina tarda alrededor de un minuto en aprovisionarse — empieza por la restauración que nunca has probado, porque es la única parte de todo esto que te dice la verdad.