Cómo respaldar una base de datos: guía práctica para MySQL, SQL Server, PostgreSQL y Oracle

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

Respaldar una base de datos no es una tarea opcional: es el seguro de vida de cualquier proyecto digital. Un fallo en el servidor, un error humano o un ataque de ransomware pueden dejar una aplicación fuera de juego si no existen copias de seguridad recientes y verificadas.

Aunque el concepto es el mismo —crear una copia coherente de los datos para poder recuperarlos—, los pasos concretos cambian según el sistema de gestión de bases de datos (DBMS): MySQL, SQL Server, PostgreSQL u Oracle. Esta guía repasa los métodos más habituales, tanto con herramientas gráficas como por línea de comandos, y cierra con buenas prácticas que conviene aplicar en producción.

Conceptos básicos antes de empezar

Antes de entrar por sistema, merece la pena aclarar algunos términos que se repetirán:

Respaldo completo: copia de todos los datos (y a veces, también de la estructura) de la base de datos.
Respaldo diferencial: copia solo de los cambios desde el último respaldo completo.
Respaldo incremental: copia solo de los cambios desde el último respaldo (sea completo o incremental).
Automatización: programar los respaldos para que se ejecuten solos en horarios definidos.
Destino seguro: guardar las copias fuera del servidor de base de datos (otro servidor, almacenamiento en red, nube, etc.).

Con esto en mente, veamos cómo se hace en los principales motores.

Cómo respaldar una base de datos MySQL

En MySQL, lo más habitual es utilizar:

Una herramienta gráfica como MySQL Workbench.
La utilidad de línea de comandos mysqldump.

Respaldo con MySQL Workbench

MySQL Workbench resulta cómodo para administradores que prefieren un entorno visual:

Abrir MySQL Workbench y conectarse al servidor.
Ir al panel lateral a la sección Administración.
Seleccionar Exportación de datos.
Elegir el esquema (base de datos) que se quiere respaldar.
Escoger el tipo de exportación:
- Exportar a Carpeta de Proyecto de Volcado: genera varios archivos .sql, uno por tabla.
- Exportar a Archivo Auto-Contenido: crea un único archivo .sql con toda la base de datos.
Pulsar en Iniciar Exportación y esperar a que finalice el proceso.

El resultado es un archivo o conjunto de archivos .sql que contienen las instrucciones necesarias para recrear tablas y datos en otro servidor o más adelante.

Respaldo con mysqldump (línea de comandos)

Para automatizar y tener más control, la herramienta clásica es mysqldump. Dos ejemplos básicos:

Exportar a un archivo de texto plano (.sql):

mysqldump -u NOMBRE_USUARIO -p NOMBRE_BASE_DATOS > /ruta/backup.sql
Lenguaje del código: JavaScript (javascript)

El sistema pedirá la contraseña tras el -p.

Exportar y comprimir en un solo paso:

mysqldump -u NOMBRE_USUARIO -p NOMBRE_BASE_DATOS | gzip > /ruta/backup.sql.gz
Lenguaje del código: JavaScript (javascript)

Este segundo comando es muy útil cuando la base de datos es grande y se quiere ahorrar espacio en disco.
En sistemas Linux o Unix, suele combinarse con cron para programar respaldos diarios o incluso horarios.

Cómo respaldar una base de datos en SQL Server

En Microsoft SQL Server, la herramienta de referencia es SQL Server Management Studio (SSMS), que ofrece un asistente gráfico muy completo.

Respaldo con SQL Server Management Studio (SSMS)

Abrir SSMS y conectarse a la instancia de SQL Server.
En el Explorador de objetos, expandir la carpeta Bases de datos.
Click derecho sobre la base de datos a respaldar → Tareas → Copia de seguridad….
En la ventana emergente, revisar:
- Tipo de copia de seguridad:
  - Completa.
  - Diferencial.
  - De registro de transacciones (en ediciones que lo soportan y cuando el modelo de recuperación lo permite).
- Destino: ruta y nombre del archivo .bak.
Opcionalmente, configurar opciones avanzadas (compresión, verificación, etc.).
Pulsar Aceptar para iniciar el respaldo.

El archivo resultante suele tener extensión .bak y puede restaurarse desde el propio SSMS o mediante RESTORE DATABASE en T-SQL.

En entornos profesionales, es habitual combinar backups completos con diferenciales e incrementales, junto con copias del registro de transacciones, para minimizar la pérdida de datos.

Cómo respaldar una base de datos PostgreSQL

En PostgreSQL, los dos caminos más comunes son:

La utilidad de línea de comandos pg_dump.
El cliente gráfico pgAdmin.

Respaldo con pg_dump (línea de comandos)

Respaldo en formato SQL de texto:

pg_dump -U NOMBRE_USUARIO -h HOST NOMBRE_BASE_DATOS > /ruta/backup.sql
Lenguaje del código: JavaScript (javascript)

Este formato genera un archivo .sql con todas las instrucciones necesarias para recrear la base de datos.

Respaldo en formato personalizado (binario):

pg_dump -U NOMBRE_USUARIO -h HOST -F c NOMBRE_BASE_DATOS > /ruta/backup.dump
Lenguaje del código: JavaScript (javascript)

El formato -F c (custom) es binario y se restaura usando pg_restore. Es más flexible para restauraciones selectivas (por ejemplo, una sola tabla).

Respaldo con pgAdmin

Abrir pgAdmin y conectarse al servidor.
En el explorador de objetos, hacer clic derecho sobre la base de datos → Backup… / Copia de seguridad….
Elegir:
- Nombre del archivo de respaldo.
- Formato de salida (por ejemplo, custom, tar o plain).
Configurar opciones adicionales (incluir roles, solo datos, solo estructura, etc.) si es necesario.
Pulsar Respaldar (Backup) para iniciar el proceso.

Este método resulta cómodo para quienes no están habituados a la línea de comandos o trabajan desde entornos gráficos.

Cómo respaldar una base de datos Oracle

En Oracle, las opciones más habituales para exportar datos y estructura son:

La herramienta Data Pump Export (expdp).
El cliente gráfico SQL Developer.

Respaldo con Data Pump Export (expdp)

Data Pump es la evolución de las antiguas utilidades exp/imp. Un ejemplo de exportación por esquema sería:

expdp USUARIO/CONTRASEÑA schemas=NOMBRE_ESQUEMA \
  directory=NOMBRE_DIRECTORIO_ORACLE \
  dumpfile=backup.dmp \
  logfile=backup.log

Algunos puntos clave:

directory no es una ruta del sistema de archivos, sino un objeto DIRECTORY de Oracle previamente creado y que apunta a una ruta del servidor.
dumpfile es el archivo binario que contiene el respaldo.
logfile guarda el registro del proceso (errores, advertencias, tiempos, etc.).

Respaldo con SQL Developer

Para escenarios más sencillos o entornos de desarrollo:

Abrir SQL Developer y conectarse a la base de datos.
Ir al menú Herramientas > Preferencias y revisar opciones en Base de datos > Utilidades > Exportar.
Usar el asistente de exportación para:
- Elegir el esquema o tablas a exportar.
- Seleccionar el formato (por ejemplo, scripts INSERT).
- Indicar si se quiere un solo archivo.
Seguir el asistente hasta generar el archivo con los datos y, si se desea, la estructura.

Este tipo de exportación es útil para mover datos entre entornos de desarrollo, hacer copias parciales o generar scripts reproducibles.

Resumen de herramientas de respaldo por motor

Motor	Línea de comandos	Herramienta gráfica principal	Formatos típicos
MySQL	`mysqldump`	MySQL Workbench	`.sql`, `.sql.gz`
SQL Server	T-SQL (`BACKUP DATABASE`) vía SSMS	SQL Server Management Studio	`.bak`
PostgreSQL	`pg_dump`, `pg_dumpall`	pgAdmin	`.sql`, `.dump`, `.tar`
Oracle	`expdp` (Data Pump Export)	SQL Developer	`.dmp` + log, scripts SQL

Buenas prácticas para respaldar bases de datos en producción

1. Automatizar siempre que sea posible

Programar tareas con cron (en Linux/Unix), Task Scheduler (en Windows) o herramientas específicas del proveedor evita depender de la intervención manual. Lo habitual es:

Respaldo completo diario o semanal (según volumen y criticidad).
Respaldo incremental o de logs con mayor frecuencia (cada pocos minutos u horas).

2. Guardar las copias fuera del servidor principal

Un fallo de disco, un incendio en el CPD o un ataque que cifre el servidor de base de datos pueden inutilizar tanto la base como sus copias si están en el mismo sitio. Lo recomendable es:

Almacenar las copias en otro servidor, en una cabina de almacenamiento, en la nube o en un repositorio remoto.
Aplicar la regla 3-2-1: 3 copias de los datos, en 2 soportes distintos, 1 en una ubicación diferente.

3. Probar restauraciones periódicamente

Tener copias no basta: hay que confirmar que se pueden restaurar. Es buena práctica:

Programar pruebas de restauración en un entorno de preproducción.
Verificar tiempos de recuperación (RTO) y punto hasta el que se puede recuperar la información (RPO).
Documentar los pasos de recuperación para no improvisar en una situación de crisis.

4. Definir una política de retención

No todos los respaldos se deben guardar para siempre. Según requisitos legales y operativos, se pueden establecer políticas como:

Diarios de los últimos 7–14 días.
Semanales de los últimos 2–3 meses.
Mensuales de los últimos 6–12 meses.

Una política clara ayuda a controlar el consumo de almacenamiento sin comprometer la capacidad de recuperación.

Preguntas frecuentes sobre respaldos de bases de datos

1. ¿Con qué frecuencia debería respaldar mi base de datos?
Depende de cuánto dato puedes permitirte perder. Si el negocio no puede perder más de 15 minutos de información, los respaldos (o la captura de logs) deben ser al menos cada 15 minutos. Como mínimo, en muchos proyectos se combina un respaldo completo diario con mecanismos de registro o respaldos incrementales más frecuentes.

2. ¿Es suficiente con hacer copias manuales de vez en cuando?
En producción, no. Las copias manuales son propensas al olvido y no garantizan regularidad. La recomendación es automatizar los respaldos y revisar periódicamente que se ejecutan correctamente y que los archivos generados no están corruptos.

3. ¿Qué es mejor: respaldos completos, diferenciales o incrementales?
No hay una respuesta única. Los respaldos completos simplifican la restauración, pero consumen más tiempo y espacio. Los diferenciales e incrementales reducen el tamaño de cada copia, pero complican algo la restauración. Lo más habitual es combinar un completo periódico (por ejemplo, semanal) con diferenciales o incrementales diarios.

4. ¿Puedo respaldar la base de datos simplemente copiando los ficheros del disco?
En la mayoría de motores, copiar los ficheros de datos “en caliente” sin usar las herramientas oficiales puede producir copias inconsistentes. Es más seguro utilizar las utilidades de respaldo del propio sistema (mysqldump, pg_dump, BACKUP DATABASE, expdp, etc.) o mecanismos integrados de snapshot que garanticen coherencia a nivel de transacción.