Copias de seguridad

Las copias de seguridad automáticas se incluyen a partir de los planes intermedios, con una frecuencia que aumenta en los planes superiores. En VPS, dependen del plan y de las opciones. El detalle figura por plan en las páginas de producto.

Sí, existe una opción de copia de seguridad diaria premium para reforzar la protección de sus datos más allá de lo que incluye su plan.

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 con precisión el archivo o la carpeta que desea restaurar desde la lista de copias de seguridad disponibles, sin tocar el resto de su cuenta. Para los VPS y los servidores dedicados, los snapshots permiten igualmente dos niveles de restauración: una restauración completa de la imagen de disco o una exploración del snapshot para extraer únicamente los archivos deseados. Esta flexibilidad evita sobrescribir datos recientes al recuperar un solo 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 programables 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 119 DH/mois, 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 su VPS ya cuenta con copias de seguridad automáticas programadas. 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. La frecuencia de las copias de seguridad automáticas incluidas varía según su plan ServOrbit; consulte /tarifs para los detalles por plan.

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 diarios automáticos incluidos en los planes VPS, con retención configurable. 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 revertirse sin una restauración. Antes de cualquier migración, exporte un dump completo con `pg_dumpall -U postgres > backup_antes_migracion.sql` y guárdelo en un almacenamiento separado de su VPS (Backblaze B2, SFTP remoto). Verifique que la restauración funciona en un entorno de prueba antes de apagar el motor antiguo. Si utiliza la opción de copia de seguridad premium de 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 automáticas están disponibles según el plan.

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.

Inicie sesión en su área de cliente de ServOrbit, abra un ticket de soporte en la categoría «Alojamiento» e indique la fecha de la copia de seguridad deseada así como la ruta o la base de datos a restaurar. Nuestro equipo realizará la restauración desde los snapshots de JetBackup lo antes posible. Si dispone de la opción JetBackup, también puede activar la restauración usted mismo directamente desde la interfaz de cPanel sin pasar por el soporte.

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.