¿Necesitas backups de tu sitio web? La regla 3-2-1, y el giro del sitio estático
Sí — y un buen backup es una copia versionada y restaurable de tu sitio guardada en algún lugar aparte del sitio mismo. Dos errores atrapan a casi todos. El primero es tratar el backup de tu hosting como el único: los hostings corren snapshots a nivel de servidor para la recuperación de infraestructura, pero si tu cuenta se compromete el backup comparte su destino, y una copia rotativa de siete días no te salvará de malware que pasó dos semanas sin detectarse. El segundo es confundir una sincronización con un backup: una sincronización refleja tus archivos actuales, así que un archivo corrupto sobrescribe el bueno de inmediato, mientras que un backup real mantiene versiones en puntos de tiempo a las que puedes volver. El estándar es la regla 3-2-1 —tres copias, en dos tipos de almacenamiento, con una afuera— ahora a menudo extendida a 3-2-1-1-0, añadiendo una copia inmutable que el ransomware no puede alcanzar y una restauración probada y verificada. En la práctica eso significa respaldar archivos y base de datos juntos, a diario para cualquier cosa que cambie, guardar 14 a 30 días de historia, y de verdad probar la restauración, porque un backup que nunca restauraste es una esperanza, no una salvaguarda. Hay un giro que recorre todo lo que construimos, sin embargo: un sitio estático no tiene base de datos que corromper ni plugins que choquen, y si su fuente vive en control de versiones, ya tiene copias versionadas, externas y portables por diseño — así que su historia de backup es mucho más simple y firme que la de un sitio de WordPress. Es también por qué, para los sitios que construimos, tu copia propia es tu backup y tu salida a la vez — y por qué ofrecemos backups automatizados como una opción, no como un upsell obligatorio.
Qué es de verdad un backup, y qué no es una sincronización
Un backup es una copia de tu sitio desde la cual puedes restaurar tras un problema, y la definición útil tiene dos partes que casi todos pasan por alto: es versionada, y es separada. Versionada significa que mantiene snapshots en puntos de tiempo en vez de solo el último estado, y esta es la distinción que separa un backup de una sincronización. Un servicio de sincronización refleja tus archivos actuales, así que cuando un archivo se corrompe o encripta esa versión dañada se sincroniza de inmediato y sobrescribe la buena; un backup apropiado mantiene copias versionadas para que puedas restaurar a un estado limpio de antes del incidente (NovaBackup, 2026).
Dos reglas prácticas siguen de para qué sirve un backup. Primero, respalda archivos y base de datos juntos, porque restaurar uno sin el otro con frecuencia te deja con un sitio que no arranca — esta es la forma más común en que un backup técnicamente presente resulta inútil (TeamUpdraft, 2026). Segundo, decide dos números antes de elegir nada: tu Objetivo de Punto de Recuperación, o cuántos datos puedes permitirte perder, y tu Objetivo de Tiempo de Recuperación, o cuán rápido necesitas volver a estar en línea — estos fijan tu cadencia y retención, y son la diferencia entre un plan y un montón de archivos (AvePoint, 2026).
La regla 3-2-1, y por qué creció
La columna de toda estrategia de backup es una regla simple de recordar: mantén tres copias de tus datos, en dos tipos distintos de almacenamiento, con una copia afuera (SentinelOne, 2026). Formalizada por el fotógrafo Peter Krogh y respaldada por CISA y NIST como el estándar canónico, su propósito entero es eliminar el “destino compartido” — el riesgo de que un solo evento destruya tanto tu sitio en vivo como tu capacidad de recuperarlo (SentinelOne, 2026).
La regla creció porque la amenaza creció. El ransomware ahora mapea entornos activamente, caza ubicaciones de backup, y las borra antes de disparar la encriptación, así que la destrucción de backups es playbook estándar de los atacantes (Object First, 2026). La respuesta es 3-2-1-1-0: el “1” extra es una copia inmutable o aislada que no puede alterarse ni con credenciales robadas, y el “0” significa cero errores — probaste una restauración y verificaste que funciona (AvePoint, 2026).
| Regla | Añade | Protege contra |
|---|---|---|
| 3-2-1 | Tres copias, dos medios, una afuera | Fallo de hardware, borrado, desastre a nivel de sitio |
| 3-2-1-1 | Una copia inmutable / aislada | Que el ransomware alcance tus backups |
| 3-2-1-1-0 | Restauraciones verificadas y probadas | Descubrir la corrupción en el peor momento |
Un detalle importa para la copia inmutable: su bloqueo debería durar más que el tiempo de permanencia típico del ransomware, de 14 a 30 días, porque los atacantes pacientes esperan a que el bloqueo expire antes de golpear (Object First, 2026).
Por qué el backup de tu hosting no basta
El error de backup más común es una suposición cómoda: que como tu hosting hace backups, estás cubierto. Los hostings confiables sí corren snapshots a nivel de servidor, pero esos sirven a la recuperación de infraestructura, no a la restauración granular de tu sitio en particular — y dejan dos brechas (MonsterMegs, 2026). La primera es el destino compartido: si tu cuenta de hosting se compromete, un backup guardado dentro de esa misma cuenta queda expuesto al mismo incidente, que es por qué la regla más vieja del libro es nunca guardar tu único backup en el mismo servidor que tu sitio en vivo (MonsterMegs, 2026).
La segunda brecha es el tiempo. Un backup rotativo de siete días no ayudará si una infección de malware pasó dos semanas sin detectarse — para cuando lo descubres, cada copia retenida ya está comprometida (MonsterMegs, 2026). El arreglo no es desconfiar de tu hosting sino añadir una copia independiente guardada en algún lugar aparte, para que un problema con el entorno de hosting no pueda tumbar tu ruta de recuperación con él. El almacenamiento en la nube lo hace barato: un sitio típico corre unos pocos gigabytes, y los backups diarios con un mes de retención cuestan casi nada al lado del precio de perder el sitio (MonsterMegs, 2026).
El paso que todos saltan: probar la restauración
Hay una frase que pertenece a todo plan de backup: un backup que nunca restauraste no es un backup, es una esperanza. El “0” de 3-2-1-1-0 existe justo porque los trabajos de backup que corren con éxito pueden aun así fallar en la restauración —un servidor puede arrancar mientras su base de datos está silenciosamente corrupta— así que el éxito tiene que medirse cuando recuperas, no cuando guardas (AvePoint, 2026).
Dos hábitos cierran esta brecha. Prueba la restauración en un calendario, al menos trimestralmente para tus datos más críticos, recuperando de verdad a un entorno de staging y confirmando que el resultado está completo y usable (NovaBackup, 2026). Y monitorea tus trabajos de backup para que sepas de inmediato cuando uno falla o corre tarde, porque un trabajo fallido que pasa dos semanas sin notarse es justo el tipo de brecha silenciosa por la que camina un incidente (NovaBackup, 2026). Probar es sin glamour y es todo el punto — una estrategia que no comprobaste es una estrategia que no tienes.
El giro del sitio estático
Aquí es donde cómo se construye un sitio cambia la conversación de backup por completo. Los backups de WordPress son tan esenciales justo porque el ecosistema de plugins de la plataforma introduce docenas de puntos de fallo potenciales —cambios de esquema, conflictos de plugins, actualizaciones fallidas— que un sitio estático simplemente nunca enfrenta (MonsterMegs, 2026). Un sitio estático no tiene base de datos que corromper ni plugins que peleen entre sí, lo que quita la mayoría de los desastres cotidianos que los backups están ahí para deshacer.
Más que eso, un sitio estático construido como construimos tiende a estar casi todo respaldado ya. Cuando la fuente vive en control de versiones, cada cambio queda rastreado, versionado y guardado afuera por diseño — eso no es un backup que compraste, es una propiedad del build. Aún quieres una copia independiente del sitio desplegado y de cualquier dato de formularios o contenido que recoge, pero la fuente propia de un sitio estático hace gran parte del trabajo que hace un plugin de backup en WordPress, y lo hace de forma más confiable porque hay menos que puede salir mal. Es el mismo patrón que el resto de esta biblioteca: hacer bien la cosa fundamental quita categorías enteras de problema, que es por qué nuestras guías sobre cómo se construye un sitio y ser dueño de tu sitio siguen llegando al mismo lugar.
Un backup es tu copia propia — y tu salida
El punto más profundo es que, para un sitio que de verdad posees, un backup y lo que te mantiene libre son el mismo objeto. Una copia completa y portable de tu sitio es lo que te deja restaurar tras un desastre y lo que te deja caminar a otro hosting cuando quieras — la copia de recuperación y la salida son una y la misma. Esa es la garantía de copia-y-vete alrededor de la que construimos: tu sitio es tuyo, tienes una copia completa portable, y esa copia es a la vez tu seguro y tu independencia.
Es también por qué tratamos los backups con honestidad en vez de como un upsell obligatorio. Para los sitios que construimos, corremos hosting confiable y ofrecemos backups externos automatizados con restauraciones probadas como una opción —belt-and-suspenders genuinamente útil para quien lo quiera— pero te diremos con claridad cuándo tu copia propia y tu fuente en control de versiones ya cubren el terreno que cubriría un plan de backup pagado. Esa postura coincide con cómo manejamos el resto de la infraestructura que corremos: un servicio real, ofrecido sin fingir que no puedes irte. La alternativa —un hosting que tiene la única copia de tu sitio— es justo la trampa contra la que advierte nuestra guía sobre ser dueño de tu sitio, donde “te respaldamos” se vuelve en silencio “te tenemos de rehén”.
Seguro que fijas una vez, y luego verificas
Los backups son el tipo más claro de cimiento de hacerlo-bien-una-vez: una disciplina pequeña y sin glamour que se sienta invisible hasta el día en que es lo único que se interpone entre ti y empezar de cero. Sigue 3-2-1, mantén una copia independiente fuera de tu hosting, retén suficiente historia para sobrevivir a un problema de combustión lenta, y —la parte que de verdad importa— prueba que puedes restaurar. Acierta eso y un hackeo, una mala actualización o un servidor caído se vuelve una molestia de una tarde en vez de una existencial.
Y el hilo hacia el resto del costo de una página web es el familiar: la opción que se ve más barata, el hosting que guarda la única copia, carga el riesgo oculto más caro, mientras que la versión disciplinada —un sitio propio, portable, versionado con una restauración probada— cuesta poco y quita una clase entera de catástrofe. Se empareja de forma natural con entender cuánto cuesta de verdad el hosting, ya que los backups y el hosting son las dos realidades recurrentes de mantener un sitio vivo, y hacer ambos bien es cómo un sitio se queda tuyo, y se queda en línea.
Frequently asked
- ¿De verdad necesito mis propios backups si mi hosting los hace?
- Sí, porque los backups de tu hosting y los tuyos sirven propósitos distintos. Los hostings confiables corren snapshots a nivel de servidor, pero esos existen para la recuperación de infraestructura, no para la restauración granular de tu sitio específico — y si tu cuenta de hosting misma se compromete, los backups guardados dentro de ella están expuestos al mismo evento, lo que se llama destino compartido. También hay una brecha de tiempo: un backup rotativo de siete días no ayuda si el malware pasó dos semanas sin detectarse. La regla segura es mantener al menos una copia independiente de tu sitio guardada aparte del entorno de hosting, para que un problema con el hosting no pueda tumbar la copia de recuperación con él.
- ¿Qué es la regla de backup 3-2-1?
- La regla 3-2-1 dice: mantén tres copias de tus datos, en dos tipos distintos de almacenamiento, con una copia guardada afuera. La formalizó el fotógrafo Peter Krogh y la respaldan CISA y NIST como el estándar base de backup. El punto es eliminar el 'destino compartido' — el riesgo de que un solo evento destruya tanto tu sitio en vivo como la capacidad de recuperarlo. Como el ransomware ahora caza y borra backups activamente, muchos equipos la extienden a 3-2-1-1-0: una de las copias es inmutable o aislada para que no pueda alterarse ni con credenciales robadas, y el cero significa que probaste una restauración y verificaste que funciona.
- ¿Cada cuánto debo respaldar mi sitio, y cuánto tiempo debo guardar los backups?
- Depende de cuán seguido cambia tu sitio. Los backups diarios sirven para cualquier cosa con contenido, pedidos o datos de clientes regulares; semanal o mensual está bien para un sitio que rara vez cambia. Sea cual sea la cadencia, guarda al menos 14 a 30 días de retención, porque algunos problemas —corrupción silenciosa, o ransomware que espera antes de dispararse— solo se vuelven visibles tras un retraso, y una ventana de retención muy corta significa que tus únicos backups ya están infectados. Respalda archivos y base de datos juntos, ya que restaurar uno sin el otro suele dejarte con un sitio que no arranca. Y corre un backup manual antes de cualquier actualización mayor.
- ¿Sincronizar mi sitio a la nube es lo mismo que respaldarlo?
- No, y la diferencia importa justo en el peor momento. Un servicio de sincronización como Dropbox o OneDrive refleja tus archivos actuales, así que si un archivo se corrompe o encripta, esa versión dañada se sincroniza de inmediato y sobrescribe la copia buena. Un backup apropiado mantiene copias versionadas en puntos de tiempo, dejándote restaurar a un estado limpio de antes de que pasara el incidente. La sincronización es conveniente para acceso y colaboración, pero no te da una forma de volver a ayer — que es toda la razón de tener un backup en primer lugar.
- ¿Un sitio estático necesita backups como uno de WordPress?
- Menos urgentemente, porque un sitio estático tiene muchas menos cosas que se puedan romper. No tiene base de datos que corromper ni plugins que choquen, lo que quita la mayoría de los puntos de fallo que hacen tan esenciales los backups de WordPress. Y si la fuente del sitio vive en control de versiones, ya tienes copias versionadas, externas y portables por diseño — cada cambio queda rastreado y recuperable. Aún quieres una copia independiente del build en vivo y de cualquier dato de formularios o contenido, pero la copia que posees de un sitio estático hace gran parte del trabajo que hace un plugin de backup en WordPress, que es una de las ventajas más silenciosas de construir así.