Copia incremental: ¿la mejor estrategia para tus archivos en la nube?

Una buena estrategia de protección de archivos no consiste en copiarlo todo cada vez, sino en decidir qué ha cambiado y cuánto tiempo puedes permitirte perder. La copia de seguridad incremental hace precisamente eso: reduce el peso de cada respaldo, acelera la captura de cambios y encaja muy bien en entornos de nube, carpetas compartidas y documentos que se editan a diario. Yo la suelo recomendar cuando hay mucho movimiento de archivos, pero también cuando el equipo necesita recuperar versiones sin disparar los costes.

Cómo funciona una copia incremental y qué guarda realmente

La lógica es simple, pero conviene entenderla bien. Primero se hace una copia completa del conjunto de datos; a partir de ahí, cada nueva ejecución solo guarda lo que ha cambiado desde la última copia, no desde el principio. Esa diferencia parece pequeña, pero en cuanto trabajas con carpetas de proyectos, documentación interna o archivos de cliente, el ahorro de tiempo y de tráfico se nota enseguida.

Yo la describo así: no vuelves a copiar el armario entero, solo las prendas que se han movido desde la última revisión. Si hoy cambian 200 MB en una carpeta de trabajo de 30 GB, no tiene sentido volver a transferir los 30 GB. La copia incremental aprovecha ese patrón de cambio y lo convierte en una cadena de respaldos más ligera.

A nivel de archivo o de bloque

Hay dos maneras habituales de detectar los cambios. En una copia a nivel de archivo, el sistema compara archivos completos y solo guarda los nuevos o modificados. En una copia a nivel de bloque, guarda pequeños fragmentos del archivo que han cambiado, lo que resulta más eficiente cuando trabajas con ficheros grandes, como bases de datos, imágenes pesadas o proyectos con muchas versiones internas.

Esto importa porque no todos los cambios pesan igual. Un documento de texto puede modificar solo unas pocas líneas; un archivo de diseño puede reescribir gran parte de su estructura interna aunque visualmente parezca que ha cambiado poco. Cuanto más fino es el nivel de captura, menos datos viajan, pero también más depende todo de que el sistema de copia esté bien integrado con el origen.

Lee también: Ficheros FTP - ¿Siguen siendo útiles o es mejor la nube?

Qué ocurre cuando toca restaurar

Aquí está el verdadero trade-off. Para recuperar un archivo o un sistema, necesitas la copia completa inicial y todas las incrementales posteriores que lleven hasta el punto que quieres restaurar. Si una de esas piezas falta o está dañada, la cadena se complica. Por eso esta técnica es muy eficiente al copiar, pero exige más disciplina al recuperar.

En un escenario real, eso se traduce en algo muy concreto: si el domingo hiciste una completa y de lunes a viernes guardaste incrementales, el viernes restauras la completa del domingo más cinco incrementales. Esa es la parte que muchos subestiman cuando solo miran el ahorro de espacio. Esa diferencia entre ahorrar al crear copias y pagar al recuperar es la clave para comparar con una completa o una diferencial.

Cuándo compensa frente a una completa o una diferencial

No me gusta venderla como una solución universal, porque no lo es. AWS lo resume bien: la incremental ahorra espacio y ancho de banda, pero la restauración requiere más pasos. En la práctica, eso significa que funciona muy bien cuando haces muchas copias, los cambios diarios son pequeños y el coste de mover datos pesa más que la velocidad de recuperación inmediata.

Si haces una completa el domingo y luego incrementales de lunes a viernes, el viernes restauras la copia completa del domingo más cinco incrementales. Con una diferencial, restauras la completa del domingo y solo la última diferencial. La diferencia es clara: la incremental gana en eficiencia diaria, pero la diferencial puede ser más cómoda cuando la prioridad es volver a operar rápido.

Hay un matiz útil para entornos con mucho volumen: la completa sintética reconstruye una nueva copia completa a partir de la base y los cambios previos, sin volver a extraer todo desde el origen. No siempre hace falta, pero en carpetas pesadas o enlaces más justos puede ser una salida muy práctica. Con eso claro, el siguiente paso es ver qué cambia cuando los archivos ya viven en la nube.

Qué cambia cuando los archivos viven en la nube

En carpetas sincronizadas, yo separo siempre tres ideas: almacenamiento, sincronización y copia de seguridad. Guardar un documento en OneDrive, SharePoint o en una carpeta sincronizada no significa automáticamente que tengas una copia independiente; si borras, sobrescribes o cifran archivos, la sincronización puede propagar el problema en lugar de resolverlo. Por eso me interesa el historial de versiones como red de seguridad, no como único plan. Microsoft permite volver a una versión anterior de un archivo en OneDrive y, además, restaurar todo el espacio de OneDrive a un punto anterior dentro de una ventana de 30 días para ciertos suscriptores. Eso ayuda mucho ante errores humanos o ransomware, pero yo no lo usaría como sustituto de una copia separada.

También conviene cuidar la consistencia. AWS recomienda pausar procesos que estén modificando el sistema de archivos o programar el backup en una franja sin cambios, porque una copia tomada mientras el archivo se está reescribiendo puede quedar a medio camino. Esa precaución importa especialmente con bases de datos ligeras, carpetas compartidas activas y proyectos que se editan a la vez por varias personas.

Cuando la nube y los archivos están bien organizados, el respaldo incremental funciona mejor porque captura cambios pequeños y frecuentes sin saturar la conexión. El siguiente paso es decidir cómo aterrizarlo en una pyme sin complicar más de la cuenta.

Cómo la configuraría yo en una pyme

Yo partiría de una pregunta muy concreta: ¿qué archivos me dolería perder hoy y durante cuánto tiempo? Si el negocio puede tolerar una hora de pérdida, ese es un RPO de 1 hora; si solo aguanta dos horas sin operar, ese límite también marca la arquitectura. A partir de ahí, montaría algo así:

1. Clasificaría los datos por criticidad. Facturación, contratos, presupuestos y archivos de clientes van primero; material temporal, cachés y descargas, después.
2. Fijaría una copia completa periódica. En equipos pequeños, una completa semanal suele ser una base razonable; en entornos más activos, puede interesar una completa sintética o una completa mensual con incrementales más frecuentes.
3. Programaría incrementales diarias o intradía. Para documentación administrativa basta muchas veces con una copia al final de la jornada; para carpetas muy movidas, cada 4 u 8 horas puede tener más sentido.
4. Separaría la copia local de la copia externa. La regla 3-2-1 sigue funcionando: tres copias, dos soportes distintos y una fuera del entorno principal.
5. Probaría una restauración real. No me interesa solo que el backup termine bien; me interesa abrir un archivo, restaurar una carpeta y comprobar que la cadena no está rota.
6. Definiría retención y permisos. Guardar 7, 30 o 90 días depende del riesgo, pero también de cuánto pesa el almacenamiento y de si necesitas rastrear cambios antiguos.

Ese esquema no es sofisticado, y precisamente por eso funciona. Cuando una pyme intenta automatizar sin decidir qué protege y qué no, acaba con copias que ocupan mucho y recuperan poco. Después de diseñar la base, el verdadero ahorro está en no cometer fallos de configuración obvios.

Los errores que la vuelven frágil cuando más la necesitas

• Confundir sincronización con copia de seguridad. Si borras o cifras un archivo y el cambio se replica, no has resuelto el problema.
• No probar la restauración. Un backup que no se ha restaurado nunca es una hipótesis, no una garantía.
• Dejar crecer demasiado la cadena. Cuantas más incrementales encadenes, más dependes de que ninguna falle.
• Copiar archivos que están en uso constante. Si el sistema o la aplicación siguen escribiendo, la copia puede no ser consistente.
• Guardar todo en el mismo proveedor o en la misma cuenta. Si el incidente es de credenciales, ransomware o borrado accidental, la única copia disponible puede quedar comprometida.
• No definir una política de retención. Sin un límite claro, acabas pagando por datos viejos o perdiendo versiones que todavía necesitabas.

Yo añadiría una precaución más: si el archivo es crítico, conviene proteger también el entorno donde se guarda el backup, por ejemplo con inmutabilidad, es decir, con una copia que no pueda alterarse durante un tiempo definido, permisos separados o una copia offline. La incremental ahorra mucho, pero no compensa una estrategia floja; por eso merece la pena cerrar con unas pocas decisiones que dejen todo atado.

Lo que yo dejaría decidido antes de ponerla en marcha

Antes de activar cualquier política, yo dejaría por escrito cinco cosas: qué se copia, cada cuánto, cuánto tiempo se conserva, dónde se restaura y quién valida la recuperación. Esa pequeña disciplina evita la falsa sensación de seguridad, que es el fallo más caro en cualquier sistema de protección de archivos.

• Alcance. Solo lo importante debe entrar en la cadena de copias.
• Frecuencia. La marca el ritmo real de cambio, no la comodidad técnica.
• Retención. 30 días puede ser suficiente para algunos equipos; otros necesitan 90 o más por motivos operativos o legales.
• Recuperación. Debe poder hacerse en minutos, no solo “algún día”.
• Prueba. Una restauración mensual ya cambia mucho la calidad del sistema.

Si alineas esas cinco piezas, la incremental deja de ser una simple forma de ahorrar espacio y se convierte en una herramienta seria para trabajar con archivos en la nube sin perder control. Yo me quedaría con esa idea: no se trata de guardar más, sino de guardar mejor y poder volver atrás sin sobresaltos.