Copias de seguridad

Las copias de seguridad automáticas se incluyen a partir de los planes de alojamiento intermedios, con una frecuencia que aumenta en los planes superiores. En VPS, nada es automático: los snapshots y las copias de seguridad se lanzan bajo demanda desde su área de cliente, según el plan y la opción Espacio de copia de seguridad. El detalle figura por plan en las páginas de producto.

No, no existe ninguna opción de copia de seguridad diaria premium. En el alojamiento compartido, la copia de seguridad diaria está incluida en el plan Pro; el plan Business incluye una copia semanal.

Según su plan, puede restaurar desde cPanel. En los demás casos, nuestro soporte realiza la restauración a petición suya.

La duración de la retención depende de su plan y de las opciones. Contacte con el soporte para conocer la retención aplicable a su plan.

Sí, los snapshots están disponibles según el plan VPS (VPS Power y VPS Business). Permiten congelar el estado del servidor antes de una operación delicada.

Dispone de acceso root: puede automatizar sus copias de seguridad con herramientas como rsync, restic o borgbackup, hacia un almacenamiento remoto de su elección.

Combine una exportación de los volúmenes Docker con una herramienta de copia de seguridad incremental como Restic o BorgBackup. Detenga temporalmente el contenedor (o utilice `docker exec` para un volcado limpio de las bases de datos), comprima el volumen y envíe después el archivo a un almacenamiento remoto. Programe la operación con cron o con un pipeline CI/CD, y versione sus archivos `docker-compose.yml` y `.env` en un repositorio git privado.

Las copias de seguridad incluidas en sus planes de alojamiento se conservan en la infraestructura de ServOrbit. Desde un VPS, puede configurar Restic o BorgBackup para enviar copias cifradas fuera del sitio hacia S3, Backblaze B2, Scaleway Object Storage o un servidor SFTP de su elección. Este enfoque es muy recomendable para cualquier dato crítico. En el Marketplace de ServOrbit hay plantillas listas para usar para estas herramientas.

Sí para MySQL y MariaDB: en el área de cliente (VPS → Gestionar → Bases de datos) puede activar una programación diaria o semanal, elegir la hora y el periodo de conservación, y los archivos se depositan en su espacio de copia de seguridad. También está disponible una copia de seguridad inmediata, confirmada mediante su contraseña y un código de un solo uso — útil justo antes de una operación sensible, como una actualización mayor del motor. Los demás motores (PostgreSQL, MongoDB…) no son detectados por esta herramienta: prevea su propia exportación y envíela hacia un almacenamiento remoto.

Sí, en los alojamientos cPanel de ServOrbit, JetBackup permite una restauración granular: usted selecciona exactamente el archivo o la carpeta que desea restaurar en la lista de copias de seguridad disponibles, sin tocar el resto de su cuenta. En un VPS, en cambio, la restauración de un snapshot afecta al snapshot entero: sustituye el estado actual del servidor, sin extracción archivo por archivo. Los servidores dedicados no disponen ni de snapshots ni de copias de seguridad incluidos: la restauración de un archivo pasa por sus propias copias de seguridad. En cPanel, esta granularidad evita sobrescribir datos recientes al recuperar un único elemento.

Restic incorpora el comando `restic check`, que recorre el repositorio y detecta cualquier corrupción de los bloques cifrados, sin necesidad de restaurar los datos. Programe esta verificación mediante un timer systemd o un cron semanal, y redirija su salida hacia un canal de alerta (correo, webhook n8n, ntfy). Si el comando devuelve un código distinto de cero, una restauración de prueba en un directorio temporal confirma rápidamente la recuperabilidad real de sus datos antes de que ocurra un incidente.

En cPanel, JetBackup permite una restauración hacia una carpeta de destino diferente en lugar de sobrescribir la ubicación de origen. Elija la opción «Restaurar en» e indique un directorio temporal; así puede comparar los archivos restaurados con los de producción antes de cualquier cambio. Este método garantiza que su sitio permanezca disponible durante la verificación. Si necesita acompañamiento, abra un ticket desde su área de cliente.

Un snapshot de VPS es una imagen instantánea del conjunto del disco de su servidor, ideal antes de una operación arriesgada; se almacena en la misma infraestructura y puede restaurarse rápidamente. JetBackup (disponible en el alojamiento cPanel) ofrece copias de seguridad incrementales automáticas de sus archivos, bases de datos y correos, almacenadas en un espacio remoto, con restauración archivo por archivo desde cPanel. Para una protección completa en VPS, combine los snapshots con una solución de copia de seguridad externa (Restic, BorgBackup).

Existen varios enfoques según el nivel de granularidad deseado. El método más directo consiste en utilizar `docker run --rm -v <volume>:/data alpine tar czf - /data` para archivar un volumen en un fichero y transferir después ese fichero hacia un almacenamiento externo mediante `rsync` o `rclone` (compatible con S3, SFTP, etc.). Para una copia de seguridad coherente de las bases de datos, es preferible un volcado a nivel de aplicación (`pg_dump`, `mysqldump`) antes que una copia bruta del volumen. Automatice estas copias de seguridad con un cron diario y conserve varias generaciones. ServOrbit ofrece igualmente snapshots de VPS bajo demanda desde el área de cliente, utilizables como red de seguridad complementaria.

Sí, es perfectamente posible restaurar una copia de seguridad de un VPS en otro VPS, por ejemplo para migrar a un plan más potente o para crear un entorno de recuperación ante desastres. **Con JetBackup** (licencia opcional de 95 DH/mes, en un servidor con cPanel): conéctese a la interfaz de JetBackup, seleccione la copia de seguridad que desea restaurar y elija **Restauración hacia otro servidor**. Indique la dirección IP del VPS de destino y las credenciales SSH. JetBackup transfiere y restaura automáticamente los datos. **Sin JetBackup**: exporte su copia de seguridad (snapshot o archivo tar) desde el área de cliente, descárguela en el VPS de destino mediante `rsync` o `scp`, y restaure manualmente. Tenga en cuenta que las direcciones IP cambian durante una migración: recuerde actualizar sus DNS y sus configuraciones de aplicación después de la restauración.

Los volúmenes Docker son el lugar donde sus aplicaciones Docker almacenan sus datos persistentes (bases de datos, archivos subidos, configuraciones). Estos son los tres enfoques para copiarlos. **Enfoque 1 — Copia directa del directorio del volumen**: los volúmenes Docker se almacenan en `/var/lib/docker/volumes/`. Cada volumen es un directorio con nombre. Puede copiarlos directamente con `tar`: `tar czf /backup/mivolumen-$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/mivolumen/_data .` **Enfoque 2 — Exportación mediante un contenedor temporal** (recomendado): este enfoque funciona sin conocer la ruta física del volumen: `docker run --rm -v mivolumen:/data -v /backup:/backup alpine tar czf /backup/mivolumen-$(date +%Y%m%d).tar.gz -C /data .` **Enfoque 3 — Snapshot de la aplicación** (para las bases de datos): utilice la herramienta nativa de la base de datos para exportar un volcado coherente antes de hacer la copia. Por ejemplo, para PostgreSQL en un contenedor: `docker compose exec -T db pg_dump -U usuario mi_base | gzip > /backup/db-$(date +%Y%m%d).sql.gz` Para automatizarlo, añada el comando a un script y prográmelo con cron. Sincronice después hacia un almacenamiento remoto con rclone para una protección fuera del sitio.

Sí: antes de cualquier actualización mayor de una aplicación self-hosted (CMS, herramienta financiera, servidor de correo…), realice una copia de seguridad completa de los archivos y de la base de datos — incluso si ya programa sus propias copias de seguridad. Una copia puntual tomada justo antes de la actualización le permite volver a un estado estable conocido en unos minutos en caso de incompatibilidad. En un VPS ServOrbit, ninguna copia de seguridad se programa automáticamente: cree un snapshot desde su área de cliente justo antes de la actualización; los snapshots y copias de seguridad incluidos en cada plan se detallan en /tarifs.

Un bare clone (`git clone --bare <url>`) copia todo el historial, las ramas y las etiquetas sin working tree, lo que lo convierte en el formato ideal para el archivado y la restauración. Desde su VPS, programe una tarea cron que ejecute `git clone --mirror` hacia un directorio de copia de seguridad y, a continuación, comprima y transfiera el archivo a un almacenamiento externo (S3, SFTP). Para profundizar, nuestra guía sobre el autoalojamiento de Gitea está disponible en `/vps-cloud`.

Antes de cualquier actualización, archive los directorios `/etc/postfix/` (configuración principal), `/etc/opendkim/` o `/etc/dkim/` (claves DKIM) y el archivo `/etc/aliases`. Utilice `tar -czf postfix-backup-$(date +%F).tar.gz /etc/postfix /etc/opendkim` y después transfiera el archivo hacia una ubicación fuera del servidor con `rsync` o `scp`. Conserve también los registros DNS TXT correspondientes para poder volver a publicar las claves en caso de pérdida. Contacte con nuestro soporte en [email protected] si necesita ayuda con la restauración.

Para PrivateGPT, haga una copia de seguridad de la carpeta `local_data/` (documentos indexados y base de datos vectorial) así como del archivo de configuración `settings.yaml`. Para LocalAI, archive el directorio de los modelos (generalmente `models/`) y los posibles archivos de configuración YAML de los perfiles. Programe una tarea `rsync` o utilice Restic para transferir estas carpetas a un almacenamiento externo; los archivos de modelos pueden ser voluminosos, piense en deduplicarlos. Encuentre nuestras plantillas PrivateGPT y LocalAI en el Marketplace ServOrbit a través de `/vps-cloud`.

Detenga primero el contenedor Mattermost (`docker compose stop mattermost`) para evitar cualquier escritura en curso y ejecute después un volcado: `docker exec mattermost-db pg_dump -U mmuser mattermost | gzip > mattermost-backup-$(date +%Y%m%d).sql.gz`. Conserve el archivo fuera del VPS (almacenamiento de objetos, transferencia `scp`/`rsync`) antes de lanzar la actualización. Para restaurar: `gunzip -c mattermost-backup-YYYYMMDD.sql.gz | docker exec -i mattermost-db psql -U mmuser mattermost`. La opción de copia de seguridad de ServOrbit toma un snapshot completo del disco — actívela como complemento para cubrir también los volúmenes de archivos.

Por defecto, Chatwoot almacena los archivos subidos en la carpeta `storage/` del contenedor — esos archivos se pierden si se recrea el contenedor. Cloudflare R2 es compatible con S3 y se utiliza sin costes de salida (egress). Atención: una incompatibilidad entre Active Storage (Rails) y R2 provoca una pérdida silenciosa de los archivos adjuntos (issue chatwoot#13299) — los archivos parecen subirse, pero se muestran con «This image is no longer available». La corrección consiste en añadir `request_checksum_calculation: "when_required"` y `response_checksum_validation: "when_required"` en el bloque de servicio R2 de `config/storage.yml`. Configure después las variables `ACTIVE_STORAGE_SERVICE=amazon`, `S3_BUCKET_NAME`, `S3_REGION`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` y `S3_ENDPOINT` en su `.env` de Chatwoot. Reinicie los contenedores y pruebe a enviar un archivo desde un ticket para validarlo.

Docmost almacena sus datos en una base de datos PostgreSQL y sus archivos (imágenes, adjuntos) en un volumen Docker o un almacenamiento de objetos compatible con S3. Para una copia de seguridad completa antes de cualquier migración o actualización mayor: (1) ejecute `pg_dump -U docmost docmost > docmost_backup_$(date +%Y%m%d).sql` sobre la base Docmost, (2) archive el volumen de almacenamiento de archivos de Docker (`docker run --rm -v docmost_storage:/data -v $(pwd):/backup alpine tar czf /backup/docmost_files_$(date +%Y%m%d).tar.gz /data`) o exporte su bucket R2/S3. (3) Programe esta copia de seguridad en un script cron en su VPS y envíe los archivos hacia un almacenamiento externo (S3, Backblaze B2 o SFTP) para evitar guardar la copia y los datos en el mismo disco.

Stalwart almacena sus datos en un directorio configurable (por defecto `/opt/stalwart-mail/data`): basta con detener el servicio, copiar esa carpeta hacia un almacenamiento remoto con Restic o BorgBackup, y después reiniciar. Procure incluir los certificados TLS (Let's Encrypt o personalizados), las claves DKIM (subcarpeta `dkim/`) y el archivo de configuración `config.toml`. Para las instalaciones Docker, monte la carpeta de datos como volumen con nombre y haga la copia de seguridad de ese volumen. Programe la copia de seguridad diaria mediante cron y compruebe periódicamente la restauración en un VPS de prueba.

La frecuencia de las copias de seguridad debe ser proporcional a su **RTO (Recovery Time Objective)** y **RPO (Recovery Point Objective)** — cuánto tiempo puede permitirse estar parado, y cuántos datos puede permitirse perder. **Recomendaciones prácticas:** | Tipo de sitio | Frecuencia | Retención | |---|---|---| | Web escaparate estática | 1×/semana | 4 semanas | | Blog activo | 1×/día | 30 días | | E-commerce | 4×/día | 30 días + 3 meses mensuales | | Aplicación crítica | 1×/hora | 48 h horarias + 30 d diarias | **Dónde almacenar las copias de seguridad — regla 3-2-1:** - **3** copias de los datos - En **2** soportes diferentes - De las cuales **1** fuera del emplazamiento principal En concreto: snapshot en el mismo VPS (rápido de restaurar) + copia hacia un bucket S3 u otro VPS (protege frente a la avería del servidor principal). **Lo que ofrece ServOrbit:** snapshots de VPS creados bajo demanda desde el área de cliente (a partir del plan VPS Power) y un espacio de copia de seguridad en un almacenamiento separado (VPS Business o como opción). Nada se programa automáticamente: la frecuencia y la retención anteriores se automatizan por su parte (cron, Restic, Borg). Los datos permanecen en Europa.

Antes de cualquier operación sensible en Plane, haga una copia de seguridad de los volúmenes Docker de la aplicación. El comando `docker compose exec plane-db pg_dump -U plane plane > plane_backup.sql` exporta la base de datos principal; complétela con una copia de los archivos de configuración (`.env`, `docker-compose.yml`) y de los posibles archivos subidos almacenados en disco. Pruebe la restauración en un entorno de prueba antes de proceder a la migración.

Sí, es imprescindible: una actualización de versión mayor de PostgreSQL (p. ej. 15 → 17) modifica el formato interno de los datos y no puede deshacerse sin una restauración. Antes de cualquier migración, exporte un volcado completo con `pg_dumpall -U postgres > backup_avant_migration.sql` y consérvelo en un almacenamiento distinto de su VPS (Backblaze B2, SFTP remoto). Compruebe que la restauración funciona en un entorno de prueba antes de detener el motor antiguo. Si utiliza los snapshots de su VPS ServOrbit, confirme que el último snapshot es reciente antes de iniciar el procedimiento.

Elasticsearch dispone de una API de Snapshot and Restore que genera copias de seguridad incrementales deduplicadas de tus índices. Configura un repositorio S3 (compatible con Backblaze B2, Cloudflare R2 o cualquier almacenamiento de objetos compatible con S3) y define una Snapshot Lifecycle Policy (SLM) para automatizar la frecuencia y la retención. Importante: nunca copies los archivos de datos directamente desde el disco mientras Elasticsearch está en ejecución — solo el mecanismo nativo de snapshots garantiza una copia coherente. Prueba una restauración en un segundo VPS periódicamente para validar la integridad.

Para un VPS en producción, apunte a al menos una copia de seguridad diaria con una retención de 7 días. Las aplicaciones críticas (bases de datos, archivos de clientes) merecen copias de seguridad horarias o incrementales. Distinga entre snapshots de sistema (útiles antes de una actualización) y copias de seguridad de datos (esenciales para la continuidad). Pruebe la restauración con regularidad: una copia de seguridad cuya restauración nunca se ha verificado es una copia no fiable. Almacene las copias en un sitio remoto o un servicio de almacenamiento de objetos independiente de su VPS.

Un snapshot es una imagen del estado del disco en un momento concreto, tomada a nivel de hipervisor: rápido de crear, permite volver atrás en minutos, pero sigue vinculado al mismo almacenamiento físico. Una copia de seguridad completa copia los datos a una ubicación separada (otro servidor, almacenamiento de objetos) y protege frente a fallos de hardware. Ambos son complementarios: los snapshots cubren errores humanos y actualizaciones fallidas; las copias de seguridad cubren desastres y pérdidas de datos. En un VPS ServOrbit, los snapshots y las copias de seguridad están disponibles según el plan y se lanzan bajo demanda desde su área de cliente.

ERPNext genera copias de seguridad comprimidas con `bench backup` en la carpeta `private/backups/` de cada sitio. Combina esto con `rclone` o la AWS CLI para enviar cada archivo a un bucket compatible con S3 (Backblaze B2, Cloudflare R2, MinIO…) justo después de su creación. Planifica todo con un cron nocturno, cifra los archivos en el lado del cliente antes de subirlos si contienen datos sensibles, y prueba periódicamente la restauración en un entorno de prueba para validar su integridad. Conserva al menos 7 copias diarias y 4 copias semanales.

En el alojamiento compartido, la restauración es en autoservicio: desde su área de cliente de ServOrbit, abra cPanel («Acceder a cPanel») y luego el menú JetBackup; elija la copia de seguridad de la fecha deseada y el elemento a restaurar (cuenta completa, archivos, base de datos). Las copias disponibles dependen de su oferta: semanales en Business, diarias en Pro; Start no incluye copias de seguridad. Si tiene dificultades, abra un ticket de soporte en la categoría «Alojamiento» indicando la fecha de la copia y la ruta o la base de datos a restaurar.

Un snapshot es una copia instantánea del disco tomada a nivel de hipervisor: ideal para revertir un error, pero reside en la misma infraestructura física que su servidor. La regla 3-2-1 va más lejos: 3 copias de los datos, en 2 soportes distintos, con 1 fuera del sitio. Si el centro de datos sufre un fallo de hardware, una inundación o la eliminación accidental de su cuenta, solo la copia externa le protege. Combine los snapshots (velocidad de recuperación) con una copia de seguridad en un almacenamiento de objetos externo (Backblaze B2, S3, Scaleway…) para cubrir ambos niveles de riesgo.

Sí, esa es precisamente la ventaja de un repositorio Restic alojado fuera de su VPS. El repositorio vive en el almacenamiento de objetos externo (S3, Backblaze B2, Scaleway…) y no tiene ninguna dependencia con su servidor: puede acceder a él desde cualquier máquina que tenga el binario de Restic, la clave de cifrado y las credenciales del repositorio. Guarde estos elementos en un gestor de secretos (Bitwarden, Vault…) independiente de su infraestructura y pruebe una restauración en una máquina de terceros al menos una vez al mes.

En cPanel, abra JetBackup, elija 'File Backups' y navegue hasta el archivo en la lista de copias de seguridad disponibles. Seleccione la fecha deseada y haga clic en 'Restore' junto al archivo para restaurarlo solo, sin afectar el resto de la cuenta. Si no encuentra el archivo, contacte a [email protected] con la ruta y la fecha objetivo.

En el alojamiento compartido, la frecuencia depende del plan: Start no incluye copia de seguridad, Business incluye una copia semanal y Pro una copia diaria. Los planes VPS tienen políticas configurables según su contrato; los servidores dedicados, por su parte, no incluyen ninguna copia de seguridad. Consulte su portal de cliente o escriba a [email protected] para conocer la política exacta de su plan.

Antes de cualquier migración mayor de PostgreSQL, realiza un volcado completo con `pg_dumpall -U postgres > backup_antes_migracion.sql` para todo el clúster, o `pg_dump -U postgres -Fc nombre_bd > nombre_bd.dump` para una base individual (formato comprimido, restaurable con `pg_restore`). Verifica que el volcado esté completo y sea legible antes de lanzar la actualización. Para restaurar, crea un clúster limpio con la nueva versión e importa con `psql` o `pg_restore`. Consulta nuestro artículo sobre la migración a PostgreSQL 18 para las precauciones específicas de esta versión.

Para una instancia Odoo en producción, una copia de seguridad completa diaria de la base de datos PostgreSQL es el mínimo recomendado. Las empresas con alto volumen de transacciones o baja tolerancia a la pérdida de datos prefieren copias de seguridad incrementales cada 4 a 6 horas. Los archivos del directorio `filestore` (adjuntos, documentos) deben respaldarse con la misma frecuencia que la base de datos para garantizar la coherencia. También se recomienda conservar al menos 7 días de copias diarias y 4 semanas de copias semanales, almacenadas en una ubicación remota o en almacenamiento de objetos independiente del VPS principal.

Antes de cualquier traslado, compruebe que su última copia de seguridad completa (archivos, bases de datos, correos) sea reciente y esté probada. En nuestros planes de alojamiento, puede lanzar una copia de seguridad manual desde cPanel en cualquier momento. En un VPS, haga un snapshot si su plan lo permite, o exporte sus volúmenes antes de la migración. Mantenga la antigua infraestructura activa hasta que el nuevo sitio esté validado y la propagación DNS haya concluido — la ventana de cambio es así reversible sin pérdida de datos.

ServOrbit no programa ninguna copia de seguridad automática de sus VPS: los snapshots y las copias de seguridad se lanzan bajo demanda desde su área de cliente, según su plan — snapshots a partir del plan VPS Power, copias de seguridad con el espacio de copia de seguridad incluido en VPS Business o como opción. La restauración de un snapshot o de una copia de seguridad está disponible como autoservicio desde su área de cliente en pocos clics. Para una protección reforzada, se recomienda combinar estas herramientas con una copia de seguridad de aplicación externa programada por su parte (por ejemplo, Borg Backup o Restic hacia almacenamiento de objetos). Los snapshots residen en el mismo almacenamiento que el VPS; solo las copias de seguridad se guardan en un almacenamiento separado, para resistir fallos de hardware.

El método recomendado es utilizar un script cron que ejecute `docker run --rm -v <volume>:/data -v /backup:/backup alpine tar czf /backup/<volume>-$(date +%F).tar.gz /data`, y luego transfiera el archivo a un almacenamiento remoto (S3, SFTP). Herramientas como Restic o Duplicati pueden automatizar este ciclo con cifrado y retención configurable. Verifica regularmente las restauraciones: una copia de seguridad no probada no es una copia de seguridad. Puedes abrir un ticket de soporte para obtener recomendaciones adaptadas a tu stack.

La duración de una restauración depende del volumen de datos y del tipo de copia de seguridad utilizada: una restauración con JetBackup de una cuenta cPanel ligera (unos cientos de MB) suele tardar menos de 30 minutos desde el área de cliente, en autoservicio. Para cuentas más voluminosas o restauraciones parciales (un solo archivo, una sola base de datos), el plazo es similar. En caso de siniestro grave que requiera la intervención de nuestro equipo, abra un ticket de prioridad urgente desde su área de cliente describiendo el impacto; nuestro equipo atiende la solicitud dentro de los plazos de nuestro SLA (99.9 % de disponibilidad). Para reducir al mínimo el riesgo de pérdida de datos, elija un plan cuya frecuencia de copias de seguridad le convenga: Business incluye una copia semanal, Pro una copia diaria.

Sí, su VPS de ServOrbit le proporciona acceso root completo: puede instalar rclone o Restic y configurar copias de seguridad automáticas hacia cualquier almacenamiento de objetos compatible con S3 (AWS S3, Backblaze B2, Wasabi…). Se recomienda programar las copias de seguridad mediante un timer de systemd o una crontab, cifrar los archivos (Restic cifra de forma nativa) y probar periódicamente una restauración completa. En el alojamiento compartido, las copias de seguridad pasan por JetBackup, integrado en cPanel: las incluidas dependen de la oferta (semanales en Business, diarias en Pro, ninguna en Start), y usted mismo las restaura desde el menú JetBackup de cPanel.

En la interfaz de Backrest, use la función de restauración seleccionando un snapshot reciente y un destino temporal (p. ej., `/tmp/restore-test`). Compruebe luego que los archivos clave están presentes y son legibles. Programe esta prueba mensualmente añadiendo una tarea automatizada en Backrest o un cron dedicado — una copia no probada no reemplaza una política de recuperación real.

Sí, Backrest permite definir múltiples repositorios en su configuración, cada uno apuntando a un backend diferente (S3, Backblaze B2, SFTP, local…). Así puede replicar sus copias de seguridad en dos buckets S3 distintos o combinar almacenamiento local y almacenamiento de objetos remoto. Cada repositorio tiene su propio calendario y política de retención.

No: los servidores dedicados ServOrbit no incluyen ni copias de seguridad automáticas ni snapshots — el servidor físico no ofrece estas funciones y la estrategia de copias de seguridad corre de su cuenta (copias periódicas a un almacenamiento externo independiente). En caso de siniestro, la restauración se hace a partir de sus propias copias de seguridad; si hay que reinstalar el sistema, la solicitud se dirige al equipo de soporte, y la reinstalación borra el disco. Para cualquier pregunta sobre la estrategia a implantar, contacte con [email protected].

Infisical cifra sus secretos en la base de datos mediante una clave de cifrado maestra (`ENCRYPTION_KEY`) independiente de los datos PostgreSQL. La buena práctica es hacer una copia de seguridad de la base PostgreSQL (volcado cifrado con Restic o pg_dump + gpg) y almacenar la `ENCRYPTION_KEY` por separado — en un gestor de secretos fuera de línea o en un vault externo — nunca en el mismo archivo ni en el mismo servidor. Así, aunque el backup de la base de datos quede comprometido, los secretos siguen siendo ilegibles sin la clave. Pruebe regularmente una restauración completa (base de datos + clave) en un entorno aislado.

Conéctate a tu VPS por SSH y ejecuta `mysqldump -u root -p nombre_de_tu_base > copia_de_seguridad.sql` para exportar una base de datos a un archivo SQL legible. Para automatizar esta copia, añade el comando a un cron job (`crontab -e`) y transfiere el archivo a almacenamiento remoto (SFTP, S3 o Backblaze B2) con `rsync` o `rclone`. ServOrbit también ofrece snapshots VPS bajo demanda desde tu área de cliente, como complemento a las copias de seguridad a nivel de aplicación.

El enfoque recomendado es ejecutar `pg_dump` mediante un temporizador de systemd o una tarea cron y luego enviar el archivo cifrado a un almacenamiento remoto (compatible con S3, SFTP) con una herramienta como Restic o Rclone. Un ciclo mínimo: copias diarias conservadas 7 días y copias semanales conservadas 4 semanas. Compruebe regularmente la restauración en un directorio temporal — un archivo no probado no es una copia de seguridad. Nuestro equipo de soporte puede orientarle desde su área de cliente.

Antes de actualizar, haga un snapshot si su plan lo permite (VPS Power y VPS Business) y después una copia del panel (cuentas, sitios, bases de datos, buzones) guardada FUERA del servidor: un snapshot se almacena en la misma infraestructura. Conserve también una copia de la configuración del panel y de sus tareas programadas. Pruebe la restauración de un sitio antes de empezar; si la actualización falla, reinstalar el sistema desde su área de cliente borra el disco: sin esa copia externa, no habrá nada que restaurar.

Restáurela en un lugar distinto de su servidor de producción: en un directorio temporal o en un segundo VPS desechable. Compruebe que los archivos clave se abren, que la base de datos arranca de nuevo con sus datos y que la aplicación responde, y anote cuánto ha tardado todo el proceso. Repita esta prueba con regularidad y tras cada cambio importante de su configuración: solo una restauración correcta demuestra que la copia sirve.

Restaurar una instantánea sustituye el estado completo del servidor: todo lo escrito después de crearla (pedidos, formularios, archivos subidos) se pierde. Antes de restaurar, copie esos datos fuera del VPS, por ejemplo una exportación de la base de datos y un archivo de las carpetas modificadas, y haga una nueva instantánea si su plan las incluye (VPS Power y VPS Business) para poder volver atrás. Después restaure, reimporte los datos recientes y compruebe el sitio antes de volver a abrirlo al público.

Una copia sana devuelve el sitio limpio, pero también restablece el fallo que permitió la intrusión: sin corregirlo, el ataque puede repetirse. Tras restaurar, actualice el núcleo, las extensiones y los temas, elimine los que ya no use, y cambie todas las contraseñas (administradores, base de datos, accesos FTP y SSH) y las claves de seguridad. Elija una copia anterior al primer rastro de compromiso, no simplemente la más reciente, y conserve una copia del estado infectado para analizarlo.