Mi Backup No Restaura: Recuperar Datos Cuando la Copia de Seguridad Falla
La sensación de seguridad que da tener una copia de seguridad puede resultar peor que no tenerla: te lleva a no actuar en caso de emergencia porque «tenías backup». Los backups fallan en silencio con mucha más frecuencia de lo que se cree: archivos de backup corruptos que jamás se verificaron, copias incompletas por errores VSS, NAS que hacía backup sobre sí mismo, o ransomware que cifró la copia junto con los originales. En RecuperaTusDatos atendemos regularmente casos de empresas y particulares que pensaban tener backup y no lo tenían cuando más lo necesitaban.
Por qué los backups fallan en silencio
La mayoría de los fallos de backup no producen ninguna alarma visible. El sistema de backup sigue ejecutándose, sigue generando archivos de backup, sigue enviando emails de confirmación — pero los datos no son restaurables. Los mecanismos de fallo silencioso más frecuentes son:
- Corrupción del archivo de backup: el archivo .bak, .vbk o el conjunto de archivos del backup se corrompe durante la escritura por un error de disco, un fallo de red o un corte de energía durante el proceso. El backup sigue existiendo, tiene el tamaño esperado, pero al intentar restaurar el software reporta «archivo de backup corrupto» o simplemente no extrae los datos correctamente.
- Backup incompleto no detectado: algunos sistemas de backup no reportan error cuando el proceso se interrumpe a mitad. El archivo existe pero solo contiene el 60% de los datos. Sin una verificación periódica de restauración real, este problema puede pasar desapercibido durante años.
- Versión incorrecta del software de restauración: algunos formatos de backup propietarios requieren exactamente la misma versión del software para restaurar. Si el software se actualizó o el sistema operativo cambió entre la creación y la restauración del backup, el proceso puede fallar.
- Cuota superada silenciosamente: los backups en la nube pueden dejar de subir datos cuando se supera la cuota de almacenamiento, sin informar al usuario de forma efectiva. El panel de control muestra el último backup «éxito» de cuando la cuota no estaba llena, pero los datos más recientes nunca se subieron.
- Ransomware que cifra el backup: el ransomware moderno explora todos los voluménes montados, incluyendo discos de backup USB conectados, unidades de red mapeadas y carpetas de sincronización con la nube. Si el backup estaba accesible desde el equipo infectado, también está cifrado.
- NAS que hace backup sobre sí mismo: un error frecuente en entornos domésticos y de pequeña empresa: el NAS hace «backup» de sus propias carpetas a otras carpetas del mismo dispositivo. Si el NAS falla, se llevan tanto el original como la copia.
El problema de no verificar los backups
La mayoría de personas y empresas nunca verifican que su backup es restaurable. Esto parece razonable cuando el backup funciona aparentemente bien, pero es un error crítico. La única forma de saber si un backup funciona es intentar restaurarlo. Verificar un backup significa:
- Restaurar el backup completo en un entorno de prueba diferente al entorno de producción.
- Verificar que los archivos restaurados se abren correctamente y tienen el contenido esperado.
- Verificar que la restauración completa tarda un tiempo aceptable para la continuidad del negocio.
- Documentar el proceso de restauración para que cualquier persona del equipo pueda ejecutarlo sin conocimientos técnicos avanzados.
Se recomienda verificar los backups al menos una vez al trimestre para entornos de empresa y una vez al año para usuarios domésticos. Para entornos críticos, la verificación automática después de cada backup es el estándar mínimo aceptable.
Fallos específicos por plataforma de backup
Cada plataforma de backup tiene sus propios modos de fallo documentados que conviene conocer:
- Windows Backup (Copia de seguridad de Windows): problemas con VSS (Volume Shadow Copy Service) son la causa más frecuente de backups incompletos. Los errores VSS pueden producirse por disco lleno, conflictos con antivirus o servicios de terceros que bloquean el snapshot. Windows Backup puede reportar «éxito» en el registro aunque el snapshot VSS haya fallado parcialmente, generando un backup del que faltan archivos abiertos en el momento del proceso.
- Time Machine (macOS): la corrupción de la base de datos de Time Machine (almacenada en el archivo .sparsebundle o en la estructura interna del disco) puede hacer que el volumen de backup sea ilegible. El síntoma típico es que Time Machine no muestra el histórico de versiones o reporta error al intentar acceder a fechas anteriores. La corrupción es más frecuente en backups sobre red (Time Capsule, NAS) que en disco externo directo.
- Veeam Backup & Replication: los jobs de Veeam pueden completarse con estado «Warning» durante semanas sin que nadie lo revise. Un warning persistente puede indicar que ciertos archivos o VMs no están siendo respaldados correctamente. Además, la restauración de un job de Veeam requiere que el repositorio de backup sea accesible; si el servidor de Veeam falla junto con el servidor de producción en el mismo incidente, la restauración puede ser imposible.
- Backup en la nube (Google Drive, OneDrive, Dropbox): estos servicios son de sincronización, no de backup en sentido estricto. Si borras un archivo en local, se borra en la nube. Si el ransomware cifra los archivos locales, la sincronización sube las versiones cifradas. El histórico de versiones (30–180 días según el plan) es la única salvaguarda, pero acceder al histórico requiere saber qué archivos recuperar y en qué fecha, lo que no siempre es obvio en un ataque masivo de ransomware.
- Backup sobre NAS con RAID: un NAS con RAID 1 o RAID 5 protege contra el fallo de un disco, pero no es un backup. Si el NAS sufre un pico de tensión, un fallo de firmware, una inundación o un robo, todos los discos del RAID se pierden simultáneamente. El RAID no reemplaza un backup en ubicación diferente.
Caso de estudio: la empresa que creía tener backup
Uno de los casos más frecuentes que atendemos en RecuperaTusDatos sigue siempre el mismo patrón. Una empresa pequeña o mediana sufre un fallo en su servidor o NAS. El responsable busca los backups y descubre uno de los siguientes escenarios:
- El backup se estaba guardando en el mismo disco físico que los datos originales — en una carpeta diferente, pero en el mismo hardware.
- El backup se hacía correctamente, pero sobre una unidad de red que estaba mapeada en el servidor y el ransomware también accedió a ella.
- El último backup válido tiene seis meses de antigüedad porque el disco de backup se llenó y nadie puso alertas de cuota.
- El software de backup se actualizó automáticamente hace tres meses y desde entonces el job falla en silencio con un código de error que nadie recibió en su bandeja de entrada.
En todos estos casos, la recuperación de datos tiene que hacerse desde el hardware original dañado, con los costes y plazos que eso implica. Si el backup hubiera sido válido, la restauración habría tardado horas; la recuperación desde hardware fallido puede tardar días y costar diez veces más.
La trampa del «backup del backup»
Otro patrón frecuente es lo que llamamos la trampa del backup del backup. El usuario, consciente de que necesita proteger sus datos, hace lo siguiente:
- Disco original con los datos → NAS en casa con todos los datos copiados.
- NAS en casa → Disco externo USB con todos los datos del NAS copiados.
- Disco externo USB → Segunda carpeta en el mismo disco externo USB.
El resultado es que tiene tres copias de los datos, pero todas en el mismo entorno físico y lógico. Un único incidente — inundación, robo, fallo del disco externo, ransomware — elimina las tres copias simultáneamente. La regla 3-2-1 (tres copias, dos soportes diferentes, una fuera de las instalaciones) existe precisamente para evitar este escenario.
Qué puede recuperarse cuando no hay backup válido
Cuando el backup falla y el hardware original está dañado, la recuperación depende del tipo y nivel de daño en el disco original. Los escenarios y sus posibilidades son:
| Escenario | Posibilidades de recuperación | Precio estimado | Plazo |
|---|---|---|---|
| Disco HDD con fallo lógico | 85–95 % | 150–350 € | 1–5 días |
| Disco HDD con daño físico | 50–80 % | 350–800 € | 5–14 días |
| SSD con fallo de firmware | 60–80 % | 300–600 € | 3–7 días |
| Ransomware (archivos cifrados) | Variable (si clave disponible) | 200–500 € + descifrado | 3–10 días |
| Servidor con RAID fallido | 60–85 % | 500–2.000 € | 7–20 días |
| NAS con múltiples discos dañados | 40–75 % | 400–1.500 € | 7–20 días |
| Disco dañado + ransomware | Baja (casos complejos) | Consultar | Consultar |
El diagnóstico es siempre gratuito y sin compromiso. Evaluamos el estado real del hardware original antes de confirmar el presupuesto. Solicita valoración gratuita aquí.
Preguntas frecuentes: backup que no restaura
Si tu backup ha fallado y necesitas recuperar datos del hardware original, solicita diagnóstico gratuito o contacta con nosotros por WhatsApp con los detalles del caso. Evaluaremos las posibilidades antes de comprometerte a nada.
WhatsApp