Cómo hacer un respaldo de tu base de datos

Un respaldo de base de datos es una copia de tus datos que puedes restaurar cuando algo sale mal: un DELETE sin WHERE, un disco que falla, una migración que corrompe tablas. La forma más portable es generar un dump: un archivo con el contenido de la base que puedes restaurar en cualquier servidor compatible.

Los comandos de MySQL, PostgreSQL y MongoDB de esta página siguen la documentación oficial de cada herramienta. Un respaldo que nunca se restauró es solo una esperanza, así que cada sección termina con la restauración.

¿Qué necesitas antes de empezar?#

• Las herramientas de línea de comandos instaladas en la máquina que hace el respaldo: mysqldump (viene con el cliente de MySQL), pg_dump y pg_restore (cliente de PostgreSQL), y mongodump y mongorestore (MongoDB Database Tools).
• Host, puerto, usuario, contraseña y nombre de la base. En una base alojada, el panel muestra la cadena de conexión.
• Un usuario con permiso de lectura sobre todo lo que vas a copiar.
• Espacio en disco para el archivo. Revisa el tamaño del primer dump antes de programar nada.
• Una base vacía para probar la restauración. Nunca pruebes restaurando sobre producción.

Evita poner la contraseña en la línea de comandos: queda en el historial del shell y en la lista de procesos. Usa variables de entorno o los archivos de configuración de las herramientas (por ejemplo ~/.my.cnf y ~/.pgpass).

¿Cómo se respalda una base MySQL?#

Usa mysqldump. Para tablas InnoDB, --single-transaction abre una transacción y lee una vista consistente sin bloquear las escrituras.

mysqldump -h "$DB_HOST" -u "$DB_USER" -p \
  --single-transaction --routines --triggers --events \
  --databases mibase > mibase.sql

--routines y --events incluyen procedimientos, funciones y eventos programados, que por defecto quedan fuera. Los triggers ya entran por defecto, y la opción solo lo hace explícito. --databases escribe también el CREATE DATABASE en el archivo. En Windows, usa --result-file=mibase.sql en lugar de la redirección >, porque PowerShell puede escribir en UTF-16 y el archivo no se podrá cargar después.

Para restaurar:

mysql -h "$DB_HOST" -u "$DB_USER" -p < mibase.sql

Como el dump se hizo con --databases, ya trae CREATE DATABASE y USE, así que no hace falta indicar el nombre de la base.

¿Cómo se respalda una base PostgreSQL?#

Usa pg_dump en formato custom (-Fc). Viene comprimido por defecto y permite restaurar solo una parte con pg_restore.

pg_dump -h "$DB_HOST" -U "$DB_USER" -d mibase -Fc -f mibase.dump

Restaura en una base nueva:

createdb -h "$DB_HOST" -U "$DB_USER" prueba_restore
pg_restore -h "$DB_HOST" -U "$DB_USER" -d prueba_restore --no-owner mibase.dump

--no-owner evita errores de ALTER OWNER cuando el usuario que restaura es distinto del original. Para restaurar sobre objetos existentes, usa --clean --if-exists. Con -j 4, pg_restore carga datos e índices en paralelo (solo en los formatos custom y directory).

Si prefieres un archivo SQL plano (pg_dump -f mibase.sql, sin -Fc), restáuralo con psql -X -h "$DB_HOST" -U "$DB_USER" -d prueba_restore -f mibase.sql.

¿Cómo se respalda una base MongoDB?#

Usa mongodump con un único archivo comprimido:

mongodump --uri="$MONGO_URI" --gzip --archive=mibase.archive.gz

Si MONGO_URI incluye la contraseña, esta queda visible en la lista de procesos (ps). La documentación recomienda omitirla de la URI para que mongodump la pida, o usar --config con un archivo YAML. Sin --db, copia todas las bases de la instancia. Para una sola, agrega --db=mibase. Para restaurar:

mongorestore --uri="$MONGO_URI" --gzip --archive=mibase.archive.gz

Agrega --drop para eliminar las colecciones existentes antes de restaurar, pero solo en un entorno de prueba o cuando estés seguro de lo que haces. Para restaurar una sola colección, usa --nsInclude="mibase.pedidos".

En un replica set, --oplog registra también las escrituras que ocurren durante el dump, de modo que el resultado represente un único instante (restaura con --oplogReplay). No se combina con --db ni con --collection, y no funciona en un clúster con sharding.

¿Y Redis?#

Redis guarda snapshots del conjunto de datos en el archivo dump.rdb, con reglas como save 60 1000 o con el comando BGSAVE. Según la documentación, el archivo no se modifica una vez generado, así que copiarlo con el servidor encendido es seguro. Respaldar Redis es copiar ese archivo. Para restaurar, colócalo en el directorio de datos antes de iniciar el servidor (con AOF activo, Redis carga el AOF en su lugar). Los detalles de persistencia están en Qué es Redis.

¿Cómo automatizarlo y guardar una copia fuera del servidor?#

Un respaldo manual se olvida. Prográmalo con cron y pon la fecha en el nombre:

#!/usr/bin/env bash
set -euo pipefail
ARCH="mibase-$(date +%F-%H%M).dump"
pg_dump -h "$DB_HOST" -U "$DB_USER" -d mibase -Fc -f "$ARCH"
rclone copy "$ARCH" destino:respaldos/  # ejemplo: envía el archivo fuera del servidor
find . -name 'mibase-*.dump' -mtime +7 -delete

Para ejecutarlo todos los días a las 3 a. m., agrega 0 3 * * * /ruta/respaldo.sh a tu crontab. Cron no carga las variables de tu shell, así que define DB_HOST y DB_USER en el propio script y deja la contraseña en ~/.pgpass. La línea con find borra los dumps de más de 7 días para que el disco no se llene.

La copia externa es la que te protege si pierdes el servidor entero y sigue la lógica de la regla 3-2-1. Un almacenamiento de objetos compatible con S3 es un buen destino, como explica backups en object storage.

¿Cómo saber que el respaldo funciona?#

1. Comprueba que el archivo no esté vacío: ls -lh, y compáralo con el dump anterior.
2. Restáuralo en una base de prueba, como en los ejemplos de arriba.
3. Compara conteos: SELECT COUNT(*) en las tablas principales, o db.pedidos.countDocuments() en MongoDB, en ambas bases.
4. Anota cuánto tardó la restauración. Ese es el tiempo de recuperación que tendrás en una emergencia.

Repite la prueba con regularidad, no solo una vez.

¿Cuáles son los errores comunes?#

• Dump parcial sin aviso: el comando falló a la mitad y el archivo quedó incompleto. Usa set -e en el script y revisa el código de salida.
• Versión de la herramienta distinta a la del servidor: usa pg_dump, mysqldump y mongodump en una versión compatible con el servidor, y restaura con la misma herramienta o una más nueva. Un cliente antiguo es fuente común de errores.
• Olvidar procedimientos y eventos en MySQL: sin --routines y --events no van al archivo.
• Contraseña en el historial del shell: usa archivos de credenciales.
• Respaldo solo en el mismo disco: perder el servidor significa perderlo todo.
• Nunca probar la restauración: el fallo aparece justo cuando más lo necesitas.

Cómo hacerlo en Square Cloud#

En el hosting de bases de datos de Square Cloud (MongoDB, PostgreSQL, MySQL y Redis, desde el plan Standard), el punto de restauración reciente ya viene en el plan. Todo plan que incluye bases de datos hace un snapshot automático diario de cada base: cada uno se conserva 7 días, y el más reciente hasta 30 días. Antes de una migración o de un DELETE arriesgado, tomas un snapshot manual desde el panel, hasta 8 por GB de RAM del plan por día.

La restauración sigue la regla de probar fuera de producción: el snapshot vuelve completo en la misma base, en otra base del mismo motor o en una base nueva, así que compruebas los conteos en una copia antes de tocar la base principal. Para guardar una copia propia, descarga el snapshot como .zip, algo que vale para todos los motores, Redis incluido.

Los dumps de esta guía siguen siendo la copia independiente y portátil. La base acepta conexiones desde fuera con host, puerto, contraseña y los certificados descargados del panel, así que el script de cron de arriba puede correr en tu máquina o en un CI. TLS es obligatorio: pasa la CA a la herramienta (--ssl-ca en mysqldump, sslrootcert en la cadena de pg_dump, --tlsCAFile en mongodump) y, en PostgreSQL y MongoDB, también el certificado del cliente (sslcert y sslkey, o --tlsCertificateKeyFile). Como cada base es de un solo nodo, sin replica set, el --oplog de mongodump no aplica.

Consulta retención, límites y restauración en Snapshots.