[Inicio](https://servhidden.com/es) / [Guías de Alojamiento Privado](https://servhidden.com/es/guides) / Backup de VPS: cifrado, fuera del sitio y que realmente restaura Operaciones # Backups de VPS que de verdad se restauran El alojamiento sin KYC elimina la red de seguridad junto con el papeleo: no se conservan copias de seguridad, los datos se destruyen en las 24 horas siguientes a la cancelación, y no hay soporte que termine en una copia recuperada. Este es el plan de trabajo: qué copiar, dónde ponerlo, cómo impedir que un atacante lo borre y cómo demostrar que se restaura. [Leer la guía](#guide-body) [Preguntas frecuentes](#guide-faq) ## En esta página - [Guía](#guide-body) - [Preguntas frecuentes](#guide-faq) - [Guías relacionadas](#guide-related) - [Páginas recomendadas](#guide-cta) Sin KYC Solo cripto Sin registros DMCA ignorado Root completo NVMe SSD 20 min de lectura Actualizado Aug 2026 En esta página [01Qué destruye realmente un servidor](#qué-destruye-realmente-un-servidor) [02Un snapshot no es un backup, y tu proveedor tampoco](#un-snapshot-no-es-un-backup-y-tu-proveedor-tampoco) [033-2-1, reescrita para gente que nunca enseñó su identificación](#3-2-1-reescrita-para-gente-que-nunca-enseñó-su-identificació) [04Push, pull, y el error que deja que una mala noche se coma las dos copias](#push-pull-y-el-error-que-deja-que-una-mala-noche-se-coma-las) [05Cifra en el origen y luego decide quién guarda la clave](#cifra-en-el-origen-y-luego-decide-quién-guarda-la-clave) [06Elegir una herramienta, en una tabla](#elegir-una-herramienta-en-una-tabla) [07Todo lo que está en ejecución no es un archivo](#todo-lo-que-está-en-ejecución-no-es-un-archivo) [08Qué respaldar, y las partes que todo el mundo olvida](#qué-respaldar-y-las-partes-que-todo-el-mundo-olvida) [09Una restauración que no has probado es un rumor](#una-restauración-que-no-has-probado-es-un-rumor) [10Automatizarlo para que siga pasando](#automatizarlo-para-que-siga-pasando) [11La versión corta](#la-versión-corta) [FAQPreguntas frecuentes](#guide-faq) [→Páginas recomendadas](#guide-cta) Una estrategia de backup nunca se pone a prueba la noche en que el servidor muere. Se pone a prueba semanas antes, en tres decisiones silenciosas que nadie apunta: dónde va la copia, quién puede borrarla y si alguien ha llegado a leerla de verdad. Un alojamiento que nunca pidió tu identidad renuncia a algo a cambio, y este es el lugar honesto para decirlo. No hay gestor de cuenta al que llamar, ni ticket que resucite un volumen borrado, y [nuestra propia política de retención](https://servhidden.com/es/privacy) es tajante sobre el motivo: los datos del servidor se destruyen en las 24 horas siguientes a la cancelación, los discos se borran criptográficamente en lugar de formatearse, y **no se conservan copias de seguridad**. Es la misma característica que hace que la plataforma merezca la pena, vista desde el otro lado. Todo lo que quieras recuperar tras una mala noche ya tiene que estar en otro sitio, y eres tú quien lo pone ahí. ## Qué destruye realmente un servidor Casi nadie pierde un servidor de la forma en que se lo imagina. El fallo catastrófico de hardware es real pero poco frecuente, y es el único caso para el que un buen proveedor ya está preparado. Las pérdidas que ocurren de verdad son más aburridas, y cada una derrota a un tipo distinto de copia, por eso «tengo un backup» no es una respuesta hasta que dices a cuál de estas sobrevive. | Qué sale mal | Cómo suele ocurrir | Qué te salva | | --- | --- | --- | | **Tu propia mano** | Un rm -rf con una variable de shell vacía, una migración apuntando a producción, un despliegue que borró la tabla equivocada | Cualquier copia fuera de la máquina de *antes* del error, lo que implica que la retención debe llegar más atrás del tiempo que tardas en darte cuenta | | **Corrupción silenciosa** | Un NVMe que se está muriendo, una escritura truncada durante un reinicio, una base de datos que lleva una semana escribiendo filas dañadas | Copias versionadas con suficiente profundidad para llegar a un punto en buen estado. Una única copia espejo refleja fielmente el daño | | **Compromiso** | Una clave robada, una aplicación sin parchear, una dependencia envenenada... y luego, de forma deliberada, tus backups | Una copia que la máquina comprometida no tenía forma de borrar. Aquí no vale nada más | | **Un incidente del proveedor o del país** | Pérdida de hardware, una acción legal en el centro de datos, una cuenta o token al que ya no puedes acceder | Una copia que no está en ese proveedor ni bajo esa jurisdicción | | **Perder la clave** | Una frase de contraseña olvidada, un keyfile borrado junto con el servidor que protegía, una cabecera LUKS que nadie exportó | **Nada.** Es la única fila sin columna de recuperación, y es más común que el fallo de hardware | Lee esta tabla como una lista de comprobación, no como una lista de miedos. Una copia nocturna a un segundo disco en la misma máquina responde a la primera fila y a nada más. Un snapshot en el mismo panel responde a las filas uno y dos. Solo una copia guardada en algún sitio al que el servidor no puede llegar, bajo una clave que aún conservas, responde a las cinco. Un destino de backup necesita disco y una dirección, no núcleos. La máquina más barata en una jurisdicción distinta es un destino perfectamente competente, y la única copia que sobrevive a un incidente en el primer proveedor. ## Un snapshot no es un backup, y tu proveedor tampoco Los snapshots son excelentes en lo suyo: deshacen una actualización que salió mal, en segundos y sin transferir nada. Lo que no pueden hacer es sobrevivir a lo que se llevó al servidor, porque comparten con él todos los dominios de fallo: el mismo proveedor, la misma cuenta, el mismo token de facturación, el mismo país, a menudo el mismo clúster de almacenamiento. Un snapshot te protege de *ti mismo*. Un backup te protege de todo lo demás. La distinción importa más aquí que en un proveedor convencional, porque las redes de seguridad habituales se quitaron a propósito. Nadie entra en los servidores de los clientes, así que nadie se da cuenta de que tu tarea de backup lleva fallando desde marzo. No hay identidad ligada a la cuenta, así que no existe la vía humana de «demuestra quién eres y te lo restauramos». Y la cancelación es terminal de verdad: un saldo vencido es un evento de pérdida de datos, no un evento de facturación. **La cláusula de las 24 horas es todo el argumento.** En esta plataforma, los datos de un servidor cancelado se destruyen en menos de un día, y los discos se borran criptográficamente en lugar de formatearse. No hay deshacer el borrado, no hay un nivel silencioso de almacenamiento en frío, no hay un resultado de soporte que termine en «encontramos una copia antigua», porque conservar una significaría guardar tus datos después de pedirnos que no lo hiciéramos. La red de seguridad y la privacidad son el mismo trato, hecho una sola vez. ## 3-2-1, reescrita para gente que nunca enseñó su identificación La regla clásica dice tres copias, en dos tipos de soporte, una de ellas fuera del sitio. Se escribió para una era de cinta y disco duro, y la cláusula del soporte ha dejado de significar nada en silencio: tu disco de producción es NVMe, el disco de tu destino de backup es NVMe, y llamar a eso «dos soportes» es un cuento que te cuentas a ti mismo. La cláusula que merece la pena conservar es la de la distancia, y en infraestructura offshore la distancia no se mide en kilómetros. Reescríbela como **tres copias, dos proveedores, dos jurisdicciones**. Los fallos que se llevan las dos copias a la vez casi nunca son físicos: son una cuenta a la que perdiste el acceso, un proveedor que tuvo una mala semana o un instrumento legal que llega a un país y no tiene alcance en otro. Dos servidores en el mismo rack son una sola copia con pasos extra; dos servidores bajo el mismo régimen legal apenas son mejores. Nuestra [guía de jurisdicciones](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) explica cómo elegir una segunda que no se limite a copiar la exposición de la primera. En la práctica esto sale barato. Un destino de backup no necesita núcleos, y apenas necesita red: necesita disco y una dirección. El [plan de VPS](https://servhidden.com/es/vps) más pequeño en una de nuestras otras [siete ubicaciones](https://servhidden.com/es/locations) es un destino perfectamente competente para restic o Borg, y para archivos medidos en terabytes, un [servidor dedicado](https://servhidden.com/es/dedicated) con discos reales cuesta menos por terabyte que cualquier almacenamiento de objetos. Cuando los datos son realmente grandes y se leen poco, la economía favorece al metal desnudo por un margen amplio. Algo que la gente hace bien en producción y mal en el destino del backup: pagarlo de la misma manera. Un segundo servidor comprado con una tarjeta a tu nombre vuelve a vincular, en silencio, la identidad que te esforzaste en quitar de la primera máquina, y ahora ese segundo servidor guarda una copia completa de todo lo que hay en ella. Si el servidor de producción se paga [en Monero](https://servhidden.com/es/guides/how-to-pay-for-hosting-with-monero), el servidor de backup merece el mismo trato. La tercera copia es la que casi todo el mundo se salta, y es la única inmune a todos los fallos remotos a la vez: un disco que tienes físicamente, actualizado de vez en cuando y mantenido offline. Una vez al mes es suficiente para la mayoría. Cuesta la atención de un café y es la copia que sobrevive a los escenarios que comparten las otras dos. ## Push, pull, y el error que deja que una mala noche se coma las dos copias Este es el montaje que casi todo el mundo construye primero. Una tarea en el servidor de producción se ejecuta cada noche, guarda una clave o un token para el destino del backup, se conecta y empuja los datos (push). Funciona, es sencillo, y tiene una propiedad que solo se hace visible el peor día de la vida del servidor: **quien controla la máquina de producción controla también los backups.** Esto no es hipotético. Borrar o cifrar los backups de la víctima antes de anunciarse es práctica habitual entre quienes hacen esto de forma profesional: las credenciales están en una tarea cron o en un archivo de entorno, y encontrarlas lleva alrededor de un minuto. Una copia que tu atacante puede borrar no es una segunda copia. Es un espejo de la primera con retraso. Hay dos soluciones limpias, y combinan bien con el [endurecimiento básico](https://servhidden.com/es/guides/first-hour-vps-hardening-checklist) que ya deberías haber hecho. - **Destinos append-only.** Las dos herramientas principales admiten un modo en el que un cliente puede añadir datos pero no puede eliminarlos. Borg lo consigue fijando la clave SSH del destino a borg serve --append-only; restic lo consigue con un servidor REST iniciado con --append-only. El servidor de producción escribe cada noche y es estructuralmente incapaz de destruir el histórico. La poda de snapshots antiguos ocurre entonces en el destino, en una sesión que la máquina de producción no puede iniciar. - **Pull en lugar de push.** Invierte la dirección: el host de backup se conecta a producción, lee y almacena. Producción no guarda ninguna credencial para el destino, así que no hay nada que robar. Restringe la clave que usa en el lado de producción con restrict y un command= forzado, para que una clave de backup robada no pueda convertirse en una shell. Pull es el modelo más sólido y cuesta un poco más de trabajo mantener; append-only es casi gratis si ya usas Borg o restic. Cualquiera de las dos convierte «el atacante borró mis backups» de un hecho consumado en un simple intento. Si te llevas una sola cosa de esta guía, que sea esta sección. ## Cifra en el origen y luego decide quién guarda la clave Las dos herramientas serias cifran en la máquina que se está respaldando, antes de que nada cruce la red. El destino almacena bloques que no puede interpretar, y eso es precisamente lo que hace segura la copia entre proveedores. Tu segundo host no necesita ser de confianza, ni siquiera amistoso; necesita ser alcanzable y tener disco. Esa única propiedad es lo que convierte «un servidor en un país del que no sé nada» de un riesgo en infraestructura. Es un mecanismo distinto al de cifrar el propio disco del servidor, y ambos responden a preguntas diferentes; nuestra guía de [cifrado de disco completo en un VPS](https://servhidden.com/es/guides/full-disk-encryption-on-a-vps) explica qué protege y qué no protege el cifrado de disco mientras la máquina está encendida. El cifrado del backup es el más fácil y el más valioso de los dos, porque su modelo de amenaza es honesto: los datos están en reposo, en un hardware que no controlas, y la clave nunca llega hasta allí. Lo cual traslada todo el riesgo a la custodia de la clave. La frase de contraseña es ahora un único punto de pérdida total, y es un punto único peor de lo que la gente espera, porque perderla es silencioso: nada se rompe, los backups siguen ejecutándose, y te enteras justo en el momento en que los necesitabas. Tres hábitos lo arreglan: - Guarda la frase de contraseña en el servidor solo como un archivo legible únicamente por root, referenciado con --password-file, para que nunca aparezca en una lista de procesos ni en el historial de la shell. - Guarda una copia legible por humanos fuera de todas las máquinas implicadas. El papel en un cajón supera de verdad a un gestor de contraseñas que sincroniza con una cuenta a la que también podrías perder el acceso. - Añade una segunda clave al repositorio, con restic key add o exportando una clave de Borg, para que una frase de contraseña olvidada sea solo una molestia y no el fin del archivo. La regla que subyace a las tres: **si la única copia de la clave vive en la máquina que el backup existe para sustituir, no tienes un backup.** Tienes un montón de bloques cifrados y una historia sobre ellos. ## Elegir una herramienta, en una tabla La elección de la herramienta importa menos que la dirección de la conexión y el estado de tu clave, por eso aparece en sexto lugar y no en el primero. Dicho esto, las diferencias son reales, y elegir la forma equivocada para el trabajo genera más trabajo después. | Herramienta | Cifra antes de salir | Deduplica | Destino append-only | Dónde encaja | | --- | --- | --- | --- | --- | | **restic** | Sí, todo el repositorio | Sí | Sí, mediante su servidor REST | La opción por defecto. Habla SFTP, almacenamiento de objetos y su propio servidor, así que el destino puede ser casi cualquier cosa | | **BorgBackup** | Sí, todo el repositorio | Sí, la mejor del grupo | Sí, de forma nativa por SSH | Un destino Linux al que se accede por SSH. Insuperable cuando los datos son grandes y repetitivos | | **rsync con rotaciones** | No: el destino ve todo | Parcial, mediante hardlinks | No | Reflejar en una máquina que controlas por completo, cuando las restauraciones parciales instantáneas importan más que la privacidad | | **rclone** | Solo con rclone crypt | No | Depende del proveedor de almacenamiento | Mover un archivo que ya existe hacia almacenamiento de objetos, o entre proveedores | | **Replicación ZFS** | Solo con un dataset cifrado | Sí, a nivel de bloque | Mediante permisos de snapshot | Replicar entre dos máquinas ZFS. Muy rápido, muy rígido en ambos extremos | | **tar con age o GPG** | Sí, si cifras el archivo | No | No aplica | Archivos pequeños, ocasionales y de conservación indefinida, donde la simplicidad gana a la eficiencia | Para un solo servidor, restic hacia un segundo VPS es el camino más corto hacia algo correcto. Para un seedbox, un archivo multimedia o cualquier cosa con muchos archivos grandes y similares, la deduplicación de Borg marca la diferencia entre un disco lleno y uno cómodo; la [guía de seedbox](https://servhidden.com/es/guides/seedbox-setup-guide) trata con más detalle el lado del almacenamiento de esa carga de trabajo. ## Todo lo que está en ejecución no es un archivo El backup corrupto más común del mundo es una copia de archivo directa de una base de datos en marcha. Termina sin ningún error, pesa lo que debe pesar, y al restaurarla obtienes una tabla que el motor se niega a abrir. La base de datos estaba a mitad de una escritura cuando pasó la copia; lo que guardaste es la foto de una página en el momento de pasarla. Tres salidas, en orden creciente de esfuerzo. Volcarla: mysqldump --single-transaction da un volcado consistente de InnoDB sin bloquear a los que escriben, y pg_dump hace lo mismo con PostgreSQL. Hacerle un snapshot: congela el sistema de archivos o toma un snapshot de LVM o ZFS, copia desde ahí y libéralo; así se gestionan los conjuntos de datos demasiado grandes para volcar cada noche. O pararla: para un servicio pequeño, dos minutos de inactividad a las 04:00 es una estrategia de consistencia perfectamente respetable, y es la única sin casos límite. La misma lógica va más allá de las bases de datos. La capa escribible de un contenedor es desechable, pero sus volúmenes no lo son, y tampoco lo son el archivo docker compose ni el entorno que lo acompaña; un backup que restaura los datos pero no la definición te deja reconstruyendo el stack de memoria. Las colas de mensajes, Redis con persistencia activada y un spool de correo que un MTA está escribiendo merecen el mismo trato: pausar, hacer snapshot o volcar, pero nunca copiar directamente y esperar lo mejor. ## Qué respaldar, y las partes que todo el mundo olvida La mayoría respalda lo obvio (la base de datos y el directorio de la aplicación) y reconstruye el resto a mano, bajo presión. Es en la reconstrucción donde se van las horas. Un backup que te devuelve a un sistema funcionando, y no a un montón de datos correctos, incluye también la capa aburrida: - /etc completo, además de las unidades y timers de systemd que escribiste, y cualquier crontab que viva fuera de él. - Los certificados TLS y sus claves privadas, o como mínimo la clave de cuenta ACME, para que los certificados se renueven en lugar de empezar de cero. - Las reglas del firewall y la lista de paquetes, que juntas reconstruyen la forma de la máquina más rápido que cualquier recuerdo de ella. - Los secretos de la aplicación y los archivos de entorno: los que excluiste deliberadamente de tu repositorio de código, y que por tanto no existen en ningún otro sitio. - Los registros DNS exportados como texto, incluidas las entradas de DNS inverso y PTR, que viven en el proveedor y no en el servidor. **Algunas claves no son datos: son identidad.** La clave privada de un servicio onion de Tor *es* la dirección: si la pierdes, el sitio no puede volver con el mismo [nombre .onion](https://servhidden.com/es/guides/how-to-host-a-tor-hidden-service), sin importar qué más hayas restaurado. La clave de un servidor WireGuard implica reemitir todas las configuraciones de cliente que hayas entregado. La clave DKIM de un servidor de correo implica un nuevo selector y empezar de cero en la [entregabilidad](https://servhidden.com/es/guides/offshore-mail-server-setup). La semilla y el estado de canales de un nodo Lightning pueden significar fondos, no archivos; la [guía de alojamiento de nodos](https://servhidden.com/es/guides/crypto-node-hosting-guide) es explícita al respecto. Copia estas claves por separado, mantenlas offline, y trátalas como más valiosas que los datos que protegen. ## Una restauración que no has probado es un rumor El software de backup informa sobre sí mismo, y lo hace con honestidad sobre lo que no importa. «Snapshot completado» significa que se escribieron datos en un repositorio. No dice nada sobre si ese repositorio se puede leer en una máquina que no es esta, por una persona que no recuerda lo que configuró hace once meses. Empieza por las comprobaciones de integridad baratas: restic check --read-data-subset=5% o borg check --verify-data con una programación regular, y entiende que verifican el archivo, no tu capacidad de usarlo. El simulacro real es distinto y lleva una tarde, una sola vez. Pide un servidor nuevo por horas en una ubicación que normalmente no usas. Restaura en él con nada más que la dirección del repositorio, la frase de contraseña y tus propias notas. Levanta el servicio. Cronometra todo el proceso. Luego destruye la máquina. Coste total: unos pocos dólares, y es el único ejercicio que produce un número en el que puedes confiar. Lo que expone de forma fiable nunca son los datos. Es el paquete que falta y que nadie apuntó, la configuración que vivía fuera de las rutas respaldadas, la frase de contraseña que solo existió en el historial de shell del servidor que intentas reemplazar, y la versión de la herramienta que sabe leer el formato de tu repositorio. Cada uno de esos problemas es trivial de arreglar de antemano y espantoso de descubrir durante una caída. Apunta los dos números que te da el simulacro: cuánto tardó la restauración y cuánto trabajo puede perder tu programación. Esa es la política de backup. Todo lo anterior es un detalle de implementación al servicio de esos dos números. ## Automatizarlo para que siga pasando Ejecuta la tarea desde un timer de systemd en lugar de cron. Obtienes los registros en un solo sitio, un historial real de la última ejecución y una programación que sobrevive a los reinicios; nada de eso te lo da cron sin trabajo extra. Mantén la frase de contraseña fuera del propio archivo de unidad, que cualquiera con acceso a la shell puede leer directamente con systemctl cat. Después resuelve el modo de fallo que de verdad atrapa a la gente, que no es un error sino el silencio. Un backup que dejó de ejecutarse hace seis semanas parece exactamente igual que uno que fue perfecto, porque ninguno de los dos produce salida. **Alerta ante la ausencia, no ante el fallo.** Haz que la tarea avise a un monitor cuando tiene éxito, y deja que el monitor se queje cuando el aviso no llega; y coloca ese monitor en cualquier sitio menos en el servidor que vigila, porque una máquina caída no puede informar de que está caída. Fija la retención de forma deliberada y no por defecto. Algo como --keep-daily 7 --keep-weekly 4 --keep-monthly 6 cubre los errores que notas esta noche y la corrupción que notas en primavera, sin crecer para siempre. Ejecuta la poda en el lado del destino si ya has pasado a append-only, que es precisamente el sentido de haberlo hecho. El volumen de transferencia rara vez es la limitación en nuestra red (el ancho de banda es ilimitado en todos los planes), así que programa pensando en la consistencia y no en una cuota, y ajusta el horario a tus propias horas tranquilas. Los hábitos más amplios en torno a todo esto se tratan en la [guía de OpSec del servidor](https://servhidden.com/es/guides/server-opsec-staying-anonymous). ## La versión corta Si no haces nada más con esta página, haz estas seis cosas, más o menos en este orden: - Pon una copia en un segundo proveedor, en una segunda jurisdicción, pagada con la misma privacidad que la primera. - Haz que esa copia sea append-only, o extráela desde el destino, para que un servidor comprometido no pueda destruirla. - Deja que la herramienta cifre en el origen, y mantén la clave fuera de las dos máquinas implicadas. - Vuelca las bases de datos y detén o haz snapshot de todo lo que esté en ejecución; nunca copies directamente un estado en vivo. - Respalda las claves de identidad por separado (onion, WireGuard, DKIM, semillas de nodo), porque esas no se pueden regenerar. - Restaura una vez en un servidor desechable, cronométralo y apunta lo que faltaba. Nada de esto es exótico, y nada de esto lleva un fin de semana. Es una tarde de configuración y un simulacro, contra una categoría de pérdida que acaba con proyectos. En una plataforma que deliberadamente no guarda nada sobre ti, la copia que hiciste tú mismo es la única que existe, y ese es el coste del trato, uno justo. [Levanta un segundo servidor](https://servhidden.com/es/vps) en una jurisdicción que no sea la primera, y dale a tu backup de esta noche un lugar donde caer. Preguntas frecuentes ## Backups de VPS: preguntas frecuentes ### 01 ¿ServHidden hace backup de mi VPS? No, y es una decisión deliberada, no un descuido. Nuestra política de retención establece que no conservamos copias de seguridad, que los datos del servidor se destruyen en las 24 horas siguientes a la cancelación y que los discos se borran criptográficamente en lugar de formatearse. Guardar una copia de tus datos después de pedirnos que los eliminemos contradiría la razón de ser de la plataforma. Todo lo que quieras que sobreviva al servidor tienes que copiarlo tú mismo, idealmente a un segundo proveedor en una segunda jurisdicción. ### 02 ¿Un snapshot es lo mismo que un backup? No. Un snapshot comparte todos los dominios de fallo con el servidor del que proviene: el mismo proveedor, la misma cuenta, el mismo país y, a menudo, el mismo almacenamiento. Es excelente para deshacer una actualización que salió mal e inútil ante la pérdida de la cuenta, el proveedor o la máquina. Trata los snapshots como un botón de deshacer y los backups como un seguro; resuelven problemas distintos y necesitas ambos. ### 03 ¿restic o BorgBackup: cuál debería usar? restic si el destino puede ser almacenamiento de objetos, SFTP o algo que aún no has decidido, porque habla con más backends que ningún otro. BorgBackup si el destino es una sola máquina Linux accesible por SSH y los datos son grandes y repetitivos, porque su deduplicación es la más fuerte del grupo. Ambos cifran en el origen antes de que nada salga de la máquina, y ambos admiten un destino append-only, lo cual importa mucho más que la elección entre ellos. ### 04 ¿Cómo evito que un atacante borre mis backups? Elimina la capacidad, no el motivo. O bien haces que el destino sea append-only, de modo que las credenciales del servidor de producción puedan añadir datos pero nunca eliminarlos, o inviertes la conexión para que el host de backup extraiga los datos de producción y el servidor de producción no guarde ninguna credencial. Borrar los backups antes de anunciarse es práctica habitual entre quienes hacen esto de forma profesional, y una copia que tu atacante puede borrar no es una segunda copia. ### 05 ¿Dónde debería estar la segunda copia? En un proveedor distinto, en una jurisdicción distinta, y pagada con la misma privacidad que tu servidor de producción. Los eventos que se llevan las dos copias a la vez casi nunca son físicos: son una cuenta perdida, un proveedor que tiene una mala semana o un requerimiento legal que alcanza a un país y no a otro. Dos servidores en el mismo rack son una sola copia con pasos extra. Como las herramientas cifran en el origen, el segundo host no necesita ser de confianza. ### 06 ¿Cada cuánto debo hacer backup? Parte de cuánto trabajo estás dispuesto a rehacer. Un blog puede perder un día sin que nadie lo note; una tienda no puede perder una hora de pedidos. Cada noche es el valor por defecto adecuado para la mayoría de configuraciones de un solo servidor, con volcados de base de datos más frecuentes si las escrituras son valiosas. Lo que importa más que la frecuencia es la profundidad de la retención: la corrupción suele notarse semanas después, así que conserva suficiente histórico para llegar a un punto anterior a que empezara. ### 07 ¿Es seguro un backup cifrado en un servidor que no controlo? En cuanto al contenido, sí: restic y Borg cifran antes de que los datos salgan del origen, así que el destino almacena bloques que no puede leer y la clave nunca viaja. Lo que el destino sí llega a conocer son metadatos: aproximadamente cuántos datos tienes, cómo cambian y cuándo se ejecutan tus tareas. Normalmente es aceptable. Si no lo es, varía el horario y mantén el repositorio en una máquina cuya titularidad no esté vinculada a la de producción. ### 08 ¿Qué pasa si pierdo la frase de contraseña del backup? El archivo desaparece para siempre, sin que nadie pueda hacer nada. Es la pérdida total más común de todo este tema y el único fallo sin ninguna vía de recuperación. Guarda la frase de contraseña fuera de todas las máquinas implicadas, prefiere el papel a una cuenta que también podrías perder, y añade una segunda clave al repositorio para que una contraseña olvidada sea solo una molestia y no el fin del archivo. Guías relacionadas ## Seguir leyendo [### Cómo Elegir una Jurisdicción de Alojamiento Offshore en 2026 Compra Un marco práctico de decisión para elegir una jurisdicción offshore: legislación de retención de datos, exposición al MLAT, postura ante DMCA, velocidad judicial y aplicación real — país por país. FAQ de 6 preguntas](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) [### VPS vs Servidor Dedicado para Cargas de Trabajo Críticas de Privacidad Compra Cuándo un VPS es suficiente, cuándo la tenencia compartida es un riesgo y cuándo el bare metal es la única respuesta honesta. Aislamiento de hardware, riesgo de hipervisor y coste frente a modelo de amenazas. FAQ de 6 preguntas](https://servhidden.com/es/guides/vps-vs-dedicated-for-privacy) [### VPN Autogestionada en un VPS Sin KYC: WireGuard vs OpenVPN Operaciones Por qué una VPN autogestionada supera a los proveedores comerciales, y cómo WireGuard y OpenVPN se comparan realmente en privacidad, rendimiento y riesgo operativo en 2026. FAQ de 6 preguntas](https://servhidden.com/es/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 para inferencia IA (y dónde encaja la RTX 5090) Compra Guía de decisión de compra: qué GPU NVIDIA elegir para LLM, imagen, video, voz y cargas de trabajo de fine-tuning autoalojadas en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, rendimiento, $/token, cuándo gana cada una. FAQ de 6 preguntas](https://servhidden.com/es/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows Offshore para Trading Forex con MT4 / MT5 / cTrader Operaciones Guía completa: por qué usar un RDP Windows para trading forex, cómo elegir una jurisdicción offshore de baja latencia, configuración de MT4 / MT5 / cTrader / Expert Advisor, latencia a servidores de broker, y el proceso de checkout sin KYC. FAQ de 6 preguntas](https://servhidden.com/es/guides/offshore-windows-rdp-for-forex-trading) [### Alojamiento Ignorado por DMCA: Lo Que Realmente Significa en 2026 Compra Qué ofrece realmente el alojamiento «ignorado por DMCA», qué jurisdicciones lo respaldan de verdad, para qué cargas de trabajo es necesario, y las trampas sobre derechos de autor que el término no cubre. FAQ de 6 preguntas](https://servhidden.com/es/guides/dmca-ignored-hosting-explained) [### Registro Anónimo de Dominios con Cripto: Privacidad WHOIS en 2026 Privacidad Una guía práctica de 2026 para registrar dominios sin revelar tu identidad: regímenes WHOIS por TLD, elección de registrador, opciones de pago en cripto, y los errores operativos que te delatan igualmente. FAQ de 6 preguntas](https://servhidden.com/es/guides/anonymous-domain-registration-with-crypto) [### Pagos Cripto para Alojamiento: Monero vs Bitcoin vs USDT Privacidad Cómo la elección de la moneda afecta lo que tu proveedor aprende sobre ti. Privacidad, comisiones, finalidad y exposición al análisis de cadena para XMR, BTC y USDT — con una recomendación clara. FAQ de 6 preguntas](https://servhidden.com/es/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### ¿Es realmente anónimo el hosting offshore? Una respuesta honesta Privacidad El hosting offshore sin KYC elimina la identidad que un proveedor normal recopila, pero «anónimo» depende del pago, del registro de logs del proveedor y de tu propia opsec. Esto es lo que realmente se puede rastrear. FAQ de 6 preguntas](https://servhidden.com/es/guides/is-offshore-hosting-truly-anonymous) [### La primera hora de hardening de un VPS: una checklist Operaciones Una checklist concreta y ordenada para asegurar un VPS nuevo en menos de una hora: claves SSH, un firewall, fail2ban, actualizaciones automáticas y la reducción de superficie de ataque que detiene la mayoría de los ataques oportunistas. FAQ de 6 preguntas](https://servhidden.com/es/guides/first-hour-vps-hardening-checklist) [### ¿Qué es el Hosting sin KYC? Definición, Legalidad y Cómo Funciona Privacidad El hosting sin KYC te permite alquilar un servidor sin ninguna verificación de identidad: sin nombre, sin correo electrónico, sin identificación. Aquí encontrarás exactamente qué significa, cómo funciona técnicamente, si es legal y cómo elegir un proveedor genuino. FAQ de 6 preguntas](https://servhidden.com/es/guides/what-is-no-kyc-hosting) [### ¿Es Legal el Hosting Offshore? La Respuesta Honesta para 2026 Compra El hosting offshore es legal, tanto para ti como para el proveedor. Aquí explicamos qué significa realmente el término, dónde está la línea legal, los mitos que vale la pena descartar y cómo utilizarlo de forma responsable. FAQ de 6 preguntas](https://servhidden.com/es/guides/is-offshore-hosting-legal) [### Cómo pagar el alojamiento con Monero (XMR) — Guía paso a paso Privacidad Guía paso a paso para pagar un VPS o servidor dedicado con Monero (XMR): por qué XMR es la opción más privada, cómo adquirirlo y cómo funciona el proceso de pago — desde la factura hasta un servidor en funcionamiento en minutos. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-pay-for-hosting-with-monero) [### Cómo alojar un sitio web de forma anónima — Guía práctica 2026 Privacidad Una guía práctica y por capas para alojar un sitio web sin revelar tu identidad: la cuenta, el pago, el dominio, la jurisdicción, la conexión y el contenido — cada capa explicada en detalle. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-host-a-website-anonymously) [### Cómo configurar una VPN WireGuard en un VPS — Guía paso a paso Operaciones Crea tu propia VPN privada en un VPS con WireGuard: por qué una VPN autoalojada supera a una comercial, la configuración completa desde la instalación hasta el primer cliente conectado, y cómo reforzar la seguridad. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Cómo alojar tu propio LLM en un servidor GPU — Guía 2026 Operaciones Ejecuta tu propio modelo de lenguaje en un servidor GPU alquilado: por qué el autoalojamiento supera a una API, qué GPU y modelo elegir, la configuración con Ollama o vLLM, y cuánto cuesta. FAQ de 6 preguntas](https://servhidden.com/es/guides/self-host-an-llm-on-a-gpu-server) [### Hosting Bulletproof vs Hosting Offshore — ¿Cuál es la diferencia? Compra El hosting bulletproof y el hosting offshore se confunden constantemente, pero no son lo mismo. Aquí encontrarás la diferencia real, por qué importa y cuál es el que verdaderamente necesitas. FAQ de 6 preguntas](https://servhidden.com/es/guides/bulletproof-vs-offshore-hosting) [### Cómo comprar un VPS con Bitcoin — paso a paso (2026) Compra Una guía accesible para comprar un VPS con Bitcoin: cómo obtener BTC, elegir un plan, pagar la factura y lo que obtienes a cambio — un servidor en funcionamiento sin tarjeta y sin nombre vinculado. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-buy-a-vps-with-bitcoin) [### Los mejores países para hosting ignorado por DMCA en 2026 Compra Dónde alojar cuando necesitas servidores fuera del alcance de las órdenes de retirada al estilo estadounidense: las jurisdicciones que funcionan, qué significa realmente «ignorado por DMCA» y cómo elegir. FAQ de 6 preguntas](https://servhidden.com/es/guides/best-countries-for-dmca-ignored-hosting) [### Cómo alojar un servicio oculto de Tor (sitio .onion) — Guía 2026 Operaciones Configura un servicio onion de Tor en un VPS: qué es un servicio oculto, por qué es la forma más sólida de alojamiento anónimo, el proceso completo de configuración y cómo mantener el anonimato real. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-host-a-tor-hidden-service) [### Configuración de un servidor de correo offshore — Aloja tu propio email privado en 2026 Operaciones Ejecuta tu propio servidor de correo privado en un VPS offshore: por qué alojar el email tú mismo, qué necesitas, la configuración práctica con una solución todo-en-uno y cómo garantizar la entregabilidad. FAQ de 6 preguntas](https://servhidden.com/es/guides/offshore-mail-server-setup) [### Guía de alojamiento de nodos cripto — Ejecuta un nodo blockchain en un VPS Operaciones Cómo alojar un nodo blockchain en un servidor: por qué ejecutar tu propio nodo, cómo dimensionar el servidor para Bitcoin, Ethereum, Monero y otras redes, la configuración inicial y cómo mantenerlo privado. FAQ de 6 preguntas](https://servhidden.com/es/guides/crypto-node-hosting-guide) [### Hosting GPU para Stable Diffusion — Monta tu propio servidor de imágenes Operaciones Ejecuta Stable Diffusion en tu propio servidor GPU: por qué autoalojar la generación de imágenes, qué GPU elegir, la configuración con una interfaz web y qué cuesta frente a un servicio alojado. FAQ de 6 preguntas](https://servhidden.com/es/guides/gpu-hosting-for-stable-diffusion) [### OpSec para servidores — Mantener el anonimato cuando gestionas un servidor Privacidad Seguridad operacional para quien gestiona un servidor anónimo: los errores que desvelan identidades, los hábitos que los previenen y cómo mantener las identidades verdaderamente separadas. FAQ de 6 preguntas](https://servhidden.com/es/guides/server-opsec-staying-anonymous) [### Guía de configuración de seedbox — Crea tu propio seedbox privado en 2026 Operaciones Cómo construir tu propio seedbox en un servidor: qué es un seedbox, cómo dimensionarlo, instalar un cliente torrent con interfaz web y mantenerlo privado y seguro. FAQ de 6 preguntas](https://servhidden.com/es/guides/seedbox-setup-guide) [### Cómo eludir la censura DPI con tu propio VPS (guía 2026) Privacidad ¿Tu VPN dejó de funcionar? Cómo eludir la censura DPI con tu propio VPS: qué detecta realmente la inspección profunda de paquetes, cuál de los cinco protocolos de 2026 vence a cada tipo de bloqueo, y una guía completa de VLESS+REALITY paso a paso. FAQ de 6 preguntas](https://servhidden.com/es/guides/bypass-dpi-censorship-with-your-own-vps) [### Cifrado de disco completo en un VPS: configurar LUKS y qué protege Operaciones Cómo cifrar un VPS con LUKS: volúmenes cifrados, cifrado de raíz completa con desbloqueo remoto por SSH, los ajustes que importan en un servidor pequeño, y qué detiene realmente el cifrado de disco. FAQ de 8 preguntas](https://servhidden.com/es/guides/full-disk-encryption-on-a-vps) [### Ocultar la IP de origen: CDN, proxy inverso y qué se filtra Privacidad Si conviene poner un CDN delante de un servidor offshore: qué oculta, el servicio de abuso que heredas, las seis formas en que la IP de origen se filtra igualmente, y cómo auditar la tuya. FAQ de 8 preguntas](https://servhidden.com/es/guides/hiding-your-origin-server-ip) [### Autoalojar un servidor Matrix: federación, metadatos y qué no cifra el E2EE Operaciones Qué cambia autoalojar tu propio servidor Matrix: Synapse frente a Conduit, el server_name que no puedes cambiar y lo que la federación sigue revelando. FAQ de 8 preguntas](https://servhidden.com/es/guides/self-host-a-matrix-server) [### Cómo migrar un sitio web a alojamiento offshore sin inactividad Operaciones El orden que convierte una migración de servidor en algo aburrido: baja el TTL de DNS con días de antelación, mantén los dos servidores en paralelo, congela las escrituras solo minutos, no horas, y limpia el rastro de DNS pasivo, Certificate Transparency y WHOIS que deja el traslado. FAQ de 8 preguntas](https://servhidden.com/es/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operaciones Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ de 8 preguntas](https://servhidden.com/es/guides/self-host-a-crypto-payment-gateway) ## Dale a tu backup de esta noche un lugar donde caer Siete jurisdicciones, ancho de banda ilimitado en todos los planes y servidores desde $7.50/mes que funcionan como destino perfecto para restic o Borg. Sin KYC, sin email, solo cripto, tanto para el destino del backup como para producción. [Ver planes VPS](https://servhidden.com/es/vps) [Servidores Dedicados](https://servhidden.com/es/dedicated) [Todas las ubicaciones](https://servhidden.com/es/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS y servidores dedicados offshore en 7 jurisdicciones privacy-friendly. Sin KYC, sin registros, solo criptomonedas. Privacidad por arquitectura.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Backup de VPS: cifrado, fuera del sitio y que realmente restaura", "description": "Tu proveedor no guarda copias. Qué destruye realmente un servidor, por qué el backup por push muere con él, restic vs Borg, y cómo probar que restaura de verdad.", "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-20T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy", "inLanguage": "es", "keywords": "backup VPS, copia de seguridad VPS cifrada, restic vs BorgBackup, backup fuera del sitio, regla 3-2-1 backup, backup append-only, backup de servidor sin KYC, cómo probar una restauración", "articleSection": "Operaciones", "wordCount": 3835 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "¿ServHidden hace backup de mi VPS?", "acceptedAnswer": { "@type": "Answer", "text": "No, y es una decisión deliberada, no un descuido. Nuestra política de retención establece que no conservamos copias de seguridad, que los datos del servidor se destruyen en las 24 horas siguientes a la cancelación y que los discos se borran criptográficamente en lugar de formatearse. Guardar una copia de tus datos después de pedirnos que los eliminemos contradiría la razón de ser de la plataforma. Todo lo que quieras que sobreviva al servidor tienes que copiarlo tú mismo, idealmente a un segundo proveedor en una segunda jurisdicción." } }, { "@type": "Question", "name": "¿Un snapshot es lo mismo que un backup?", "acceptedAnswer": { "@type": "Answer", "text": "No. Un snapshot comparte todos los dominios de fallo con el servidor del que proviene: el mismo proveedor, la misma cuenta, el mismo país y, a menudo, el mismo almacenamiento. Es excelente para deshacer una actualización que salió mal e inútil ante la pérdida de la cuenta, el proveedor o la máquina. Trata los snapshots como un botón de deshacer y los backups como un seguro; resuelven problemas distintos y necesitas ambos." } }, { "@type": "Question", "name": "¿restic o BorgBackup: cuál debería usar?", "acceptedAnswer": { "@type": "Answer", "text": "restic si el destino puede ser almacenamiento de objetos, SFTP o algo que aún no has decidido, porque habla con más backends que ningún otro. BorgBackup si el destino es una sola máquina Linux accesible por SSH y los datos son grandes y repetitivos, porque su deduplicación es la más fuerte del grupo. Ambos cifran en el origen antes de que nada salga de la máquina, y ambos admiten un destino append-only, lo cual importa mucho más que la elección entre ellos." } }, { "@type": "Question", "name": "¿Cómo evito que un atacante borre mis backups?", "acceptedAnswer": { "@type": "Answer", "text": "Elimina la capacidad, no el motivo. O bien haces que el destino sea append-only, de modo que las credenciales del servidor de producción puedan añadir datos pero nunca eliminarlos, o inviertes la conexión para que el host de backup extraiga los datos de producción y el servidor de producción no guarde ninguna credencial. Borrar los backups antes de anunciarse es práctica habitual entre quienes hacen esto de forma profesional, y una copia que tu atacante puede borrar no es una segunda copia." } }, { "@type": "Question", "name": "¿Dónde debería estar la segunda copia?", "acceptedAnswer": { "@type": "Answer", "text": "En un proveedor distinto, en una jurisdicción distinta, y pagada con la misma privacidad que tu servidor de producción. Los eventos que se llevan las dos copias a la vez casi nunca son físicos: son una cuenta perdida, un proveedor que tiene una mala semana o un requerimiento legal que alcanza a un país y no a otro. Dos servidores en el mismo rack son una sola copia con pasos extra. Como las herramientas cifran en el origen, el segundo host no necesita ser de confianza." } }, { "@type": "Question", "name": "¿Cada cuánto debo hacer backup?", "acceptedAnswer": { "@type": "Answer", "text": "Parte de cuánto trabajo estás dispuesto a rehacer. Un blog puede perder un día sin que nadie lo note; una tienda no puede perder una hora de pedidos. Cada noche es el valor por defecto adecuado para la mayoría de configuraciones de un solo servidor, con volcados de base de datos más frecuentes si las escrituras son valiosas. Lo que importa más que la frecuencia es la profundidad de la retención: la corrupción suele notarse semanas después, así que conserva suficiente histórico para llegar a un punto anterior a que empezara." } }, { "@type": "Question", "name": "¿Es seguro un backup cifrado en un servidor que no controlo?", "acceptedAnswer": { "@type": "Answer", "text": "En cuanto al contenido, sí: restic y Borg cifran antes de que los datos salgan del origen, así que el destino almacena bloques que no puede leer y la clave nunca viaja. Lo que el destino sí llega a conocer son metadatos: aproximadamente cuántos datos tienes, cómo cambian y cuándo se ejecutan tus tareas. Normalmente es aceptable. Si no lo es, varía el horario y mantén el repositorio en una máquina cuya titularidad no esté vinculada a la de producción." } }, { "@type": "Question", "name": "¿Qué pasa si pierdo la frase de contraseña del backup?", "acceptedAnswer": { "@type": "Answer", "text": "El archivo desaparece para siempre, sin que nadie pueda hacer nada. Es la pérdida total más común de todo este tema y el único fallo sin ninguna vía de recuperación. Guarda la frase de contraseña fuera de todas las máquinas implicadas, prefiere el papel a una cuenta que también podrías perder, y añade una segunda clave al repositorio para que una contraseña olvidada sea solo una molestia y no el fin del archivo." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Inicio", "item": "https://servhidden.com/es/" }, { "@type": "ListItem", "position": 2, "name": "Guías de Alojamiento Privado", "item": "https://servhidden.com/es/guides" }, { "@type": "ListItem", "position": 3, "name": "Backup de VPS: cifrado, fuera del sitio y que realmente restaura", "item": "https://servhidden.com/es/guides/vps-backup-strategy" } ] } ```