Saltar al contenido principal

Resguardo y restauración

Esta guía describe el procedimiento operativo para respaldar y restaurar una instalación on-premise de Mawidabp. Cubre la base de datos PostgreSQL y los archivos de usuario (papeles de trabajo, firmas, adjuntos).

nota

Todos los comandos deben ejecutarse con usuario root. Los comandos que corren sobre PostgreSQL lo hacen bajo el usuario del sistema postgres.

Qué se respalda​

Dos bloques independientes:

  • Base de datos PostgreSQL (mawidabp_production): todos los datos estructurados de la aplicación (organizaciones, usuarios, planes, informes, hallazgos, bitácora).
  • Archivos de usuario (/var/www/mawidabp.com/shared/private): papeles de trabajo, adjuntos, logos, firmas.

El respaldo completo requiere ambos bloques. Restaurar sólo la base deja archivos huérfanos; restaurar sólo archivos deja referencias rotas.

Resguardo​

1. Respaldar la base de datos​

su -l postgres -c "pg_dump mawidabp_production | bzip2 > /tmp/mawidabp_production.sql.bz2"

El dump se comprime con bzip2 (también es válido gzip o xz si preferís otro compresor).

2. Respaldar los archivos de usuario​

cp -a /var/www/mawidabp.com/shared/private /tmp/mawidabp-private-backup

O preferentemente comprimirlo y versionarlo:

tar czf /tmp/mawidabp-private-$(date +%F).tar.gz -C /var/www/mawidabp.com/shared private

3. Mover los respaldos a almacenamiento seguro​

Subir ambos archivos (mawidabp_production.sql.bz2 y el .tar.gz de private) a un almacenamiento externo:

  • Un bucket S3 con versionado habilitado.
  • Un almacenamiento de red (NFS, SMB) con snapshots.
  • Cualquier solución corporativa que cumpla el RPO/RTO del equipo.
tip

Automatizá el resguardo con cron o una herramienta corporativa (Control M, Rundeck, etc.). Una frecuencia típica es diaria para la base y diaria o semanal para los archivos, según cuánto crecen.

Restauración​

1. Detener los servicios​

systemctl stop unicorn
systemctl stop sidekiq

2. Copiar los archivos de respaldo al servidor​

Asumamos que los archivos llegaron a:

  • /tmp/mawidabp_production.sql.bz2 — dump de la base.
  • /tmp/mawidabp/private — archivos de usuario.

3. Descomprimir la base (si vino comprimida)​

bzip2 -d /tmp/mawidabp_production.sql.bz2

Esto deja /tmp/mawidabp_production.sql listo para restaurar.

4. Restaurar la base de datos​

Crear la base (si no existe todavía) y cargar el dump:

su -l postgres -c psql

Dentro de psql:

CREATE DATABASE mawidabp_production WITH OWNER mawidabp;
\q

Cargar el dump:

su -l postgres -c "psql mawidabp_production < /tmp/mawidabp_production.sql"
aviso

Si ya existe una base mawidabp_production con datos, CREATE DATABASE va a fallar. Decidí si:

  • DROP y recrear (perdés los datos actuales).
  • Restaurar en otra base (por ejemplo mawidabp_restore) y mover los datos manualmente.

5. Restaurar los archivos de usuario​

mv /tmp/mawidabp/private /var/www/mawidabp.com/shared/private

Ajustar permisos si hace falta:

chown -R deployer:deployer /var/www/mawidabp.com/shared/private

6. Iniciar los servicios​

systemctl start unicorn
systemctl start sidekiq

7. Verificación​

  • Ingresar a Mawidabp con un usuario conocido.
  • Abrir un informe reciente y verificar que los papeles de trabajo adjuntos se abren correctamente (si los PDFs no abren, suele ser permisos del directorio private).
  • Revisar los logs en /var/log/mawidabp/ por errores durante el arranque.

Crear un usuario de solo lectura​

Para reportes externos o herramientas de BI, a veces conviene crear un usuario PostgreSQL con permisos de solo lectura.

  1. Acceder como postgres:
cd /
su - postgres
  1. Entrar al cliente de PostgreSQL:
psql
  1. Crear el usuario y otorgar permisos:
CREATE USER auditoria WITH ENCRYPTED PASSWORD '<contraseña-fuerte>';
GRANT CONNECT ON DATABASE mawidabp_production TO auditoria;
\c mawidabp_production;
GRANT USAGE ON SCHEMA public TO auditoria;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO auditoria;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO auditoria;
REVOKE INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public FROM auditoria;
  1. Probar la conexión:
psql -U auditoria -d mawidabp_production

Con esto el usuario puede leer todas las tablas pero no modifica ni borra nada.

peligro

No reutilices la contraseña del ejemplo (123asd). Usá una contraseña fuerte, distinta del usuario principal, y guardala en un gestor de secretos.

Estrategia recomendada​

  • Frecuencia: dump diario de la base, respaldo diario o semanal de private/. Según el volumen de cambios diarios, incrementales para private/ pueden ahorrar espacio.
  • Retención: 7 días on-site, 30 días off-site. Para algunas regulaciones puede necesitarse retención anual.
  • Verificación: restaurar el respaldo más reciente en un servidor de staging mensualmente. Un respaldo que nunca se probó puede estar corrupto sin que nadie lo sepa.
  • Cifrado: si los respaldos salen del datacenter, cifrar el archivo (openssl o gpg) antes de subir.

Soporte​

Si la restauración falla o querés revisar la estrategia de respaldo, escribí a soporte@mawidabp.com.