Cómo hacer una copia de seguridad de un VPS en un S3 balde con Cipi
Por Andrea Pollastri · Última actualización: · lectura gratuita, sin muro de pago
Un volcado que se encuentra en el mismo disco que la aplicación es una instantánea, no una copia de seguridad. Esta guía recorre todo el circuito externo conCipi: cree un depósito, almacene las credenciales una vez, ejecute la primera carga, prográmela, elimine las antiguas y restaure en un VPS limpio para que sepa que el plan funciona.
- Por qué el volcado del mismo disco no es una copia de seguridad
- Lo que realmente sube Cipi
- lo que necesitas
- Crea el bucket
- Configurar Cipi una vez
- Primera copia de seguridad y verificación.
- Cron, retención y poda
- Simulacro de restauración
- Copia de seguridad antes de cada lanzamiento
- Errores que inutilizan las copias de seguridad
- Preguntas frecuentes
Por qué el volcado del mismo disco no es una copia de seguridad
Instantáneas del proveedor, una .sql.gz en /var/log, un tarball al lado storage/ — todos mueren con la máquina. Disco lleno, ransomware, un dedo gordo rm -rf, un corte de región, un VPS robado: la copia que necesitas es la que ya estaba en otro lugar.
La regla que aún se mantiene es 3-2-1: tres copias, dos medios, uno fuera del sitio. Cipi cubre el último salto. cipi db backup le brinda una reversión local rápida; cipi backup run envía la base de datos y el shared/ carpeta a Amazon S3 o cualquier depósito compatible con S3. Esa es la copia que restauras cuando desaparece el VPS.
Una copia de seguridad que nunca has restaurado es una esperanza, no un plan. Haga un presupuesto de 20 minutos después de la primera carga exitosa y realice el ejercicio en Restaurar. Repítelo cada trimestre.
Lo que realmente sube Cipi
Cada ejecución crea un prefijo con marca de tiempo en el depósito:
Dentro de esa carpeta obtienes dos archivos:
db.sql.gz— un volcado comprimido de la base de datos de la aplicación (mariadb-dump --single-transaction, o el equivalente PostgreSQL si la aplicación utiliza ese motor).shared.tar.gz- todo el/home/<app>/shared/directorio:.env,storage/, archivos cargados y cualquier otra cosa que sobreviva a un intercambio de versión de Deployer.
El código no está en el archivo. Lanzamientos en vivo en Git; Si necesita el último árbol bueno, clone el repositorio. Lo que no se puede clonar es la base de datos y los archivos que los usuarios cargaron después de la puesta en marcha; esos dos archivos son el punto de restauración.
desde v4.7.14 la puesta en escena ocurre en el disco en /var/tmp, no en una memoria RAM /tmp. Las aplicaciones grandes ya no mueren a la mitad porque los tmpfs se llenaron. Anular con tmpdir en backup.json o el CIPI_BACKUP_TMPDIR variable de entorno.
lo que necesitas
- Un VPS ya gestionado por Cipi. Si estás empezando desde cero, ejecuta
wget -O - https://cipi.sh/setup.sh | bashen una caja nueva Ubuntu 24.04/26.04, luegocipi app create. el guía de introducción cubre la instalación. - Al menos una aplicación en ese servidor.
cipi backup runsin nombre realiza una copia de seguridad de cada aplicación;cipi backup run myappapunta a uno. - Un depósito compatible con S3 o S3 y una clave de acceso que pueda escribir en él. Cree un usuario de IAM dedicado: no reutilice sus credenciales de nube raíz.
Crea el bucket
Elija un proveedor, cree un depósito privado en una región que sea no el mismo centro de datos que el VPS y crear un par de claves con alcance únicamente para ese depósito. Habilite el cifrado del lado del servidor si el proveedor lo ofrece. El control de versiones es un seguro opcional pero económico contra una sobrescritura accidental.
Acciones mínimas de IAM en ese depósito: s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject. El último sólo es necesario si lo deseas. cipi backup prune para limpiar prefijos antiguos.
| Proveedor | URL de punto final |
|---|---|
| AWS S3 | dejar vacío |
| Almacenamiento de objetos Hetzner | https://<datacenter>.your-objectstorage.com |
| Espacios DigitalOceánicos | https://<region>.digitaloceanspaces.com |
| Resplandor B2 | https://s3.<region>.backblazeb2.com |
| MiniIO | https://your-minio-host |
| Johnny (self-hosted S3) | tu URL pública de Johnny |
Cualquier tienda compatible con S3 sirve. Si desea la copia externa en una segunda factura de SaaS de su propiedad (no en otra factura de SaaS), Johnny es la opción open-source ya mencionada en el self-hosted pila de desarrollador.
Configurar Cipi una vez
Inicie sesión mediante SSH como usuario administrador, conviértase en root y ejecute el asistente. escribe /etc/cipi/backup.conf y no deberías tener que volver a tocarlo a menos que cambie la llave o el cubo.
# as root on the VPS
$ cipi backup configure
# → AWS Access Key ID
# → AWS Secret Access Key
# → Bucket name
# → Region
# → Endpoint URL (empty for AWS; required for everyone else)mantener /etc/cipi/backup.conf modo 600 y propiedad de root. Esas claves abren todas las copias de seguridad que realice. Si una clave pierde, gírela en el proveedor y ejecute cipi backup configure de nuevo, los objetos viejos permanecen en el cubo; Sólo las nuevas cargas utilizan la nueva clave.
cipi db backup Funciona sin configuración. cipi backup run no lo hace. Si el comando S3 falla con un error de credenciales, omitiste este paso.
Primera copia de seguridad y verificación.
No ponga nada en cron hasta que un recorrido manual haya aterrizado en el cubo. Comience con una sola aplicación:
$ cipi backup run myapp
# → s3://your-bucket/cipi/myapp/2026-08-22_143015/db.sql.gz
# → s3://your-bucket/cipi/myapp/2026-08-22_143015/shared.tar.gz
$ cipi backup list myapp
$ cipi backup run
# no app name = every app on the serverLuego confirme desde la consola del proveedor, o con AWS CLI, que también se comunica con puntos finales compatibles si aprueba --endpoint-url:
$ aws s3 ls s3://your-bucket/cipi/myapp/
$ aws s3 ls s3://your-bucket/cipi/myapp/2026-08-22_143015/Deberías ver ambos objetos, con tamaños que coincidan con un volcado comprimido más el shared/ árbol. Un objeto de 200 bytes generalmente significa un volcado vacío o una carga fallida; solucione eso antes de programar algo.
Cron, retención y poda
Todos los días a las 02:00 es el aburrido valor predeterminado. Pode a las 03:00 para que la carrera de ayer nunca se borre con una carrera. Cuatro semanas de historial son suficientes para la mayoría de las aplicaciones Laravel; baje a dos si le duele la factura del cubo, suba a ocho si necesita solucionar un error de datos de combustión lenta.
# crontab -e as root
0 2 * * * /usr/local/bin/cipi backup run myapp >> /var/log/cipi/backup.log 2>&1
0 3 * * * /usr/local/bin/cipi backup prune myapp --weeks=4 >> /var/log/cipi/backup-prune.log 2>&1Para hacer una copia de seguridad de cada aplicación en el cuadro, suelte el nombre de la aplicación en ambos comandos. cipi backup prune lee lo mismo /etc/cipi/backup.conf y funciona con cualquier proveedor compatible.
$ cipi backup prune myapp --weeks=4
$ cipi backup prune myapp --weeks=2ver /var/log/cipi/backup.log durante una semana. Un cron silencioso que falló el primer día es la forma en que las personas descubren que no tienen copias de seguridad a la mañana siguiente de la muerte del disco.
Simulacro de restauración
Haga esto en una aplicación de prueba, o en un VPS de repuesto, no en tráfico en vivo la primera vez. El feliz camino desde un prefijo S3 hasta una aplicación en ejecución:
$ cipi backup list myapp
$ aws s3 cp s3://your-bucket/cipi/myapp/2026-08-22_143015/db.sql.gz /tmp/db.sql.gz
$ cipi db restore myapp /tmp/db.sql.gz
$ aws s3 cp s3://your-bucket/cipi/myapp/2026-08-22_143015/shared.tar.gz /tmp/shared.tar.gz
$ tar -xzf /tmp/shared.tar.gz -C /home/myapp/Si el VPS ya no está, la secuencia es: instale Cipi en una nueva caja Ubuntu, cipi app create con el mismo control remoto de Git, luego las dos restauraciones anteriores, luego cipi ssl install y un corte DNS. el documentos de infraestructura enumerar los mismos comandos; Este ejercicio es la parte que la mayoría de la gente se salta.
Para una reversión del mismo servidor (mala migración, mala implementación), el volcado local es más rápido:
$ ls -lh /var/log/cipi/backups/myapp_*.sql.gz
$ cipi db restore myapp /var/log/cipi/backups/myapp_20260822_143012.sql.gz
$ cipi deploy myapp --rollbackVertederos locales en /var/log/cipi/backups/ nunca se eliminan automáticamente. En una apretada agenda de implementación, llenan el disco. Quédate con los últimos cinco y suelta el resto: ls -t /var/log/cipi/backups/myapp_*.sql.gz | tail -n +6 | xargs rm -f.
Copia de seguridad antes de cada lanzamiento
Webhook la implementación automática no puede pausarse para realizar una copia de seguridad: se activa el envío cipi deploy inmediatamente. Para producción, coloque una etapa de respaldo en CI para que un volcado fallido bloquee el lanzamiento. Las GitHub acciones completas y los GitLab ejemplos se encuentran en Implementación segura: copia de seguridad antes del lanzamiento. Los dos comandos que necesitas en esa etapa:
$ cipi db backup myapp
# fast local rollback
$ cipi backup run myapp
# off-site copy of DB + shared/Usados en conjunto, obtienes una restauración del mismo cuadro que toma unos segundos y un prefijo S3 que aún puedes abrir si el cuadro ya no está. Si cualquiera de los comandos falla, no lo implemente.
Errores que inutilizan las copias de seguridad
- Misma región que VPS, misma cuenta de proveedor, sin segunda copia. Una cuenta suspendida o una interrupción regional requiere ambas cosas. Coloque el depósito en otra región o en otro proveedor.
- Claves de nube raíz en el servidor.Un usuario de IAM dedicado con cuatro acciones S3 en un depósito es suficiente. Si el VPS se ve comprometido, el radio de explosión permanece en ese nivel.
- Nunca probando la restauración. Banderas de compresión, volcados vacíos, un
shared/extracto que sobrescribe el árbol incorrecto; solo encontrará esos errores durante un incidente a menos que profundice. - Sin ciruela pasa, luego una factura sorpresa.Los volcados diarios de 2 GB se convierten en 60 GB al mes. conjunto
--weeksel mismo día que configuraste cron. - Confiar únicamente en las instantáneas del proveedor. Son convenientes. También están en la misma cuenta, a menudo en la misma región, y no te dan un teléfono portátil.
db.sql.gz. - saltando
shared/. Una base de datos sin archivos cargados es media aplicación.cipi backup runya empaca ambos; no invente un volcado cron "para que sea simple".
Ejecútelo en un Cipi VPS
Cipi es el open-source Laravel despliegue CLI gratuito que se utiliza en esta guía. Un comando convierte un Ubuntu VPS nuevo en un servidor de producción reforzado, y cipi backup configure es el paso que hace que el servidor pueda sobrevivir.
Preguntas frecuentes
¿Funciona Cipi solo con Amazon S3?
No. cipi backup configure acepta cualquier punto final compatible con S3: Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO o una tienda self-hosted como Johnny. Deje el punto final vacío para AWS; llénelo para todos los demás proveedores.
¿Cuál es la diferencia entre cipi db backup y cipi backup run?
cipi db backup escribe un volcado de SQL comprimido en el mismo VPS bajo /var/log/cipi/backups/. Siempre está disponible y no necesita configuración. cipi backup run vuelca la base de datos y la aplicación shared/ carpeta, luego sube ambos archivos a su depósito S3. Utilice el volcado local para una reversión rápida; utilice la copia S3 para una restauración real fuera del sitio.
¿Con qué frecuencia debo hacer una copia de seguridad de un Laravel VPS?
Diariamente es el valor predeterminado sensato para la producción. Añadir cipi backup run al crontab raíz en una hora tranquila, luego pode cuando tenga más de cuatro semanas. Si la base de datos cambia constantemente, ejecútela dos veces al día. Ejecute siempre una copia de seguridad antes de una migración riesgosa o una implementación de producción.
¿Puedo restaurar una copia de seguridad Cipi S3 en una nueva VPS?
Sí, ese es el objetivo de una copia externa. Instale Cipi en un Ubuntu VPS nuevo, vuelva a crear la aplicación, descargue db.sql.gz y shared.tar.gz desde el depósito, restaure la base de datos concipi db restorey extraer shared/ en /home/<app>/.
¿Dónde almacena Cipi las credenciales S3?
cipi backup configure les escribe a /etc/cipi/backup.conf. Mantenga ese archivo solo como raíz. Las mismas credenciales son utilizadas por cipi backup run, list y prune. La preparación de archivos grandes por defecto es /var/tmp entonces una pequeña RAM respaldada /tmp no aborta el trabajo.
