La frase “RAID no es backup” se ha repetido tanto que ya casi suena a pegatina de portátil. El problema es que mucha gente la repite, asiente, y luego monta un NAS con discos en espejo como si eso resolviera el miedo de perder fotos, documentos o datos de una aplicación.
RAID ayuda. Los snapshots ayudan. Los backups ayudan. Pero ayudan a cosas distintas. Cuando mezclas esas tres capas en la cabeza, aparece la falsa seguridad. Y la falsa seguridad es peor que el miedo, porque al menos el miedo te hace comprobar.
En un homelab doméstico, donde conviven servicios de laboratorio con cosas que sí importan, esta separación me parece básica. No por purismo. Por supervivencia operativa. Quiero saber qué me protege de un disco muerto, qué me protege de borrar algo por error, qué me protege de una actualización que rompe datos y qué me protege si el servidor entero desaparece.
Spoiler poco glamuroso: ninguna capa lo hace todo.
La forma corta de entenderlo#
Yo lo resumo así:
- RAID mantiene un sistema disponible cuando falla un disco.
- Un snapshot permite volver atrás dentro del mismo sistema.
- Un backup permite recuperar datos fuera del sistema original.
Esa frase ya evita media desgracia.
RAID responde a “se ha muerto un disco, ¿puedo seguir funcionando?”. Snapshot responde a “he cambiado o borrado algo, ¿puedo volver al estado anterior?”. Backup responde a “he perdido el sistema, ¿puedo recuperar los datos en otro sitio?”.
Son preguntas diferentes. Por eso me incomoda cuando alguien dice “tengo RAID, así que tengo copias” o “tengo snapshots, así que estoy cubierto”. No. Tienes una parte del problema cubierta. A veces una parte muy útil, pero solo una parte.
RAID: disponibilidad, no redención#
RAID tiene un objetivo bastante concreto: tolerar el fallo de uno o varios discos, según el tipo de RAID, sin perder el volumen o sin parar el servicio. En un NAS familiar o un servidor de almacenamiento, eso es valioso. Un disco muere y no tienes que reconstruir toda tu vida digital desde cero esa misma tarde.
Pero RAID replica también tus errores. Si borras una carpeta, se borra en el conjunto. Si una aplicación corrompe una base de datos, esa corrupción vive feliz en discos redundantes. Si entra ransomware y cifra archivos, RAID guarda los archivos cifrados con la misma eficacia. Si una fuente de alimentación se lleva el servidor por delante, que hubiese espejo de discos igual no te salva.
RAID tampoco te protege de errores humanos. Y en homelab, el error humano suele ser el disco más peligroso del rack.
Aun así, no lo desprecio. Para almacenamiento principal, me gusta tener redundancia. No quiero que un fallo normal de disco se convierta en una restauración completa. La disponibilidad también importa en casa. Si ahí viven fotos, documentos, media o backups locales, tener que apagar todo por un disco muerto es una faena.
Lo que no hago es contar RAID como backup. Lo cuento como continuidad.
Snapshots: el botón de “antes de tocar”#
Los snapshots son una maravilla cuando se usan bien. Antes de actualizar una VM, tocar una configuración delicada o probar una migración, un snapshot te da una salida rápida. Si algo sale mal, vuelves atrás.
En ZFS, Btrfs, Proxmox o sistemas similares, los snapshots pueden ser muy baratos al principio porque guardan diferencias. Eso los hace tentadores. Y ahí empieza el peligro. Como son fáciles, uno empieza a acumularlos. Como parecen copias, uno empieza a confiar demasiado.
Un snapshot no sustituye un backup por varias razones:
- Suele vivir en el mismo almacenamiento.
- Depende del mismo servidor o pool.
- Puede desaparecer si pierdes el sistema original.
- No siempre es consistente para aplicaciones con base de datos.
- Puede crecer y comerse espacio si lo dejas sin control.
Para mí, el snapshot es una cuerda corta. Sirve para volver a hace cinco minutos, una hora, un día, quizá una semana. No sirve para dormir tranquilo durante años.
Donde sí me parece muy potente es antes de cambios. Actualización de contenedores con datos importantes, cambios en una VM, migración de una aplicación, retoques en un servicio crítico. Snapshot, cambio, prueba, limpieza. Si todo va bien, no hace falta coleccionar snapshots como si fueran cromos.
Backups: la capa que tiene que sobrevivir fuera#
Un backup empieza a ser backup cuando puedo recuperar datos aunque el sistema original esté roto, borrado o inaccesible. Esa es mi línea mental.
Puede ser otra máquina, otro disco, otro NAS, una nube cifrada o una combinación. Lo importante no es solo que exista una copia. Lo importante es que esa copia no dependa completamente del mismo fallo que intentas cubrir.
Si las fotos están en un NAS y el backup está en otra carpeta del mismo NAS, eso ayuda contra un borrado torpe si hay permisos o snapshots de por medio, pero no contra la muerte del NAS. Si la base de datos de una app se copia a otro disco interno del mismo servidor, algo es algo, pero no lo llamaría recuperación seria. Si tienes una copia fuera de casa pero nunca has probado a restaurar, tienes esperanza con formato de archivo.
En Backup 3-2-1 para homelab la idea base era tener varias copias, en medios distintos y una fuera. En la práctica doméstica, yo lo aterrizo así:
- Copia local rápida para restaurar sin sufrir.
- Copia en otro dispositivo o servidor para fallo de máquina.
- Copia externa cifrada para desastre real.
- Prueba de restauración, aunque sea pequeña.
La última es la que más se salta la gente. Normal. Da pereza. Pero es la parte que convierte “creo que tengo backup” en “sé que puedo recuperar”.
Ejemplo realista: fotos familiares#
Pensemos en fotos familiares, porque ahí se acaba la tontería rápido. Una app tipo galería self-hosted puede ser muy cómoda, pero también concentra mucho miedo. Las fotos no son una cacharrada. No quieres perderlas porque una noche te dio por actualizar con sueño.
Una arquitectura razonable podría tener:
- Almacenamiento principal en un NAS con discos redundantes.
- Snapshots frecuentes del dataset de fotos.
- Backup local a otro disco o servidor.
- Backup externo cifrado.
- Exportación o copia de la base de datos de la aplicación.
Cada capa cubre algo distinto.
Si muere un disco, RAID mantiene el volumen vivo. Si borras por error una carpeta, snapshot. Si el NAS muere, backup local o externo. Si una actualización rompe la base de datos, snapshot o dump anterior. Si hay robo, incendio o desastre eléctrico, copia externa.
¿Es mucho? Depende de cuánto te importen las fotos. Para una app de pruebas, es ridículo. Para recuerdos familiares, me parece bastante sensato.
La clave no es montar el sistema más complejo posible. Es ajustar la protección al valor real del dato.
Ejemplo realista: una VM de laboratorio#
Ahora pensemos en una VM donde pruebo cosas. Ahí no quiero la misma liturgia.
Puede bastar con:
- Snapshot antes de cambios grandes.
- Backup ocasional si la VM contiene algo reusable.
- Nada más si es desechable.
No todo merece RAID, backup externo y ceremonia. De hecho, tratarlo todo como crítico acaba consiguiendo lo contrario: te cansas, dejas de revisar y el sistema se llena de trabajos que nadie entiende.
Para laboratorio soy bastante frío. Si no contiene datos importantes y puedo reconstruirlo, no merece protección seria. Quizá merece un README o un Compose guardado en Git. Poco más.
Esto libera energía para proteger bien lo que sí duele.
Ejemplo realista: documentos y contraseñas#
Documentos y contraseñas están en otra liga. No suelen ocupar demasiado, pero perderlos es un golpe serio.
Aquí me gusta pensar en dos cosas: datos y acceso.
Los datos son los archivos, bases de datos y adjuntos. El acceso son las claves, tokens, 2FA, URL, certificados y forma de entrar. Un backup de un gestor de contraseñas que no puedes descifrar porque perdiste la clave maestra no sirve. Un backup perfecto guardado en una ubicación para la que necesitas el propio gestor caído tiene un punto cómico bastante oscuro.
Para este tipo de servicios prefiero:
- Exportación o backup cifrado y probado.
- Copia fuera del servidor principal.
- Documentación mínima de recuperación.
- Acceso de emergencia pensado antes del susto.
Los snapshots aquí son útiles antes de actualizar. RAID ayuda a que un disco no te arruine el día. Pero la recuperación real tiene que poder hacerse desde fuera del sistema.
El error de hacer snapshots eternos#
Una trampa clásica es dejar snapshots durante meses. Al principio parecen gratis. Luego empiezan a retener cambios, crecer, complicar limpieza y convertir el almacenamiento en una especie de vertedero histórico.
Mi regla práctica:
- Snapshots frecuentes para corto plazo.
- Retención clara.
- Nada de snapshots manuales olvidados.
- Antes de borrar uno, entender si era parte de una replicación.
Si quiero historia larga, prefiero backups diseñados para eso. Los snapshots son geniales como protección de corto recorrido. Para archivo histórico, auditoría o recuperación de meses, usaría una estrategia de backup.
También intento nombrarlos bien. “antes-actualizar-app-2026-07” dice algo. “snapshot1” es una nota de suicidio administrativo.
El error de no separar permisos#
Otro fallo habitual: el mismo sistema que puede escribir los datos puede borrar todos los backups.
Si una aplicación, usuario o máquina comprometida tiene permisos para modificar datos y eliminar copias, tienes una cadena demasiado blanda. En casa no siempre vamos a montar seguridad enterprise, pero hay mínimos razonables.
Me gustan las copias con cierta resistencia:
- Repositorios de backup con credenciales separadas.
- Destinos donde el cliente puede escribir pero no borrar fácilmente.
- Retención gestionada desde el servidor de backup, no desde la app.
- Copia externa con versionado.
Esto importa especialmente contra borrados torpes y malware. RAID no ayuda ahí. Snapshots pueden ayudar si el atacante o el error no los toca. Backups con permisos separados ayudan más.
Cómo combino las tres capas#
Mi esquema mental para servicios importantes es este:
Primero, redundancia si el servicio necesita disponibilidad. No siempre. Para almacenamiento principal sí suele tener sentido. Para una VM secundaria, quizá no.
Segundo, snapshots antes de cambios y con retención corta. Me sirven para deshacer meteduras de pata recientes.
Tercero, backups con copia fuera del sistema original. Me sirven para recuperar cuando el sistema original ya no merece confianza.
Cuarto, prueba. Sin prueba, todo lo anterior pierde peso.
La prueba no tiene que ser heroica. Restaurar un archivo, levantar una base de datos en entorno temporal, verificar que el repositorio abre, comprobar que la clave descifra. Lo suficiente para que el día malo no sea la primera vez que lees la documentación.
En backups que sí miro conté cómo prefiero comprobaciones pequeñas y constantes antes que una gran ceremonia anual. Sigo pensando igual. La disciplina pequeña gana.
Qué no haría#
No confiaría solo en RAID para nada que me importe.
No confiaría solo en snapshots para fotos, documentos o bases de datos importantes.
No guardaría el único backup en el mismo servidor que los datos originales.
No automatizaría borrados de copias sin entender la retención.
No montaría una estrategia tan compleja que luego me dé pereza mantenerla.
Esta última es la más importante. En homelab hay una tentación constante de diseñar como si fuésemos una empresa pequeña. A veces tiene sentido. Muchas veces no. Prefiero una estrategia simple que se ejecuta y se prueba a una arquitectura preciosa que nadie mira.
Mi regla final#
Cuando dudo, hago esta pregunta: “¿Qué fallo estoy cubriendo con esta capa?”.
Si no puedo responder, probablemente estoy mezclando conceptos.
RAID cubre fallo de disco y continuidad. Snapshots cubren vuelta atrás cercana. Backups cubren pérdida o corrupción del sistema original. Copia externa cubre desastre físico o fallo total de ubicación. Pruebas de restauración cubren autoengaño.
Esa separación no es académica. Es lo que evita mirar un NAS roto pensando “pero tenía RAID” o buscar un snapshot después de perder el pool entero.
El almacenamiento en casa no necesita paranoia infinita. Necesita honestidad. Qué datos importan, qué fallos pueden pasar, cuánto tiempo aceptas estar caído y cuánto dolor te supondría perderlo todo.
A partir de ahí, RAID, snapshots y backups dejan de ser palabras sueltas y empiezan a ser capas. Cada una con su trabajo. Cada una con sus límites.
Y el límite más importante conviene tatuarlo mentalmente: si no puedes restaurarlo en otro sitio, todavía no lo llames backup.