Skip to main content

Backup and restore

This guide describes the operational procedure to back up and restore an on-premise Mawidabp installation. Covers the PostgreSQL database and user files (working papers, signatures, attachments).

note

All commands must be run as root. Commands that run on PostgreSQL do so as the postgres system user.

What gets backed up​

Two independent blocks:

  • PostgreSQL database (mawidabp_production): all the application's structured data (organizations, users, plans, reviews, findings, system log).
  • User files (/var/www/mawidabp.com/shared/private): working papers, attachments, logos, signatures.

A complete backup requires both blocks. Restoring only the database leaves orphan files; restoring only files leaves broken references.

Backup​

1. Back up the database​

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

The dump is compressed with bzip2 (also valid: gzip or xz if you prefer another compressor).

2. Back up user files​

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

Or, preferably, compress and version it:

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

3. Move the backups to safe storage​

Upload both files (mawidabp_production.sql.bz2 and the private .tar.gz) to external storage:

  • An S3 bucket with versioning enabled.
  • Network storage (NFS, SMB) with snapshots.
  • Any corporate solution that meets the team's RPO/RTO.
tip

Automate the backup with cron or a corporate tool (Control M, Rundeck, etc.). A typical frequency is daily for the database and daily or weekly for the files, depending on how much they grow.

Restore​

1. Stop the services​

systemctl stop unicorn
systemctl stop sidekiq

2. Copy the backup files to the server​

Let's assume the files arrived at:

  • /tmp/mawidabp_production.sql.bz2 — database dump.
  • /tmp/mawidabp/private — user files.

3. Decompress the database (if it came compressed)​

bzip2 -d /tmp/mawidabp_production.sql.bz2

This leaves /tmp/mawidabp_production.sql ready to restore.

4. Restore the database​

Create the database (if it does not exist) and load the dump:

su -l postgres -c psql

Inside psql:

CREATE DATABASE mawidabp_production WITH OWNER mawidabp;
\q

Load the dump:

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

If a mawidabp_production database already exists with data, CREATE DATABASE will fail. Decide whether to:

  • DROP and recreate (you lose the current data).
  • Restore into another database (for example, mawidabp_restore) and move data manually.

5. Restore the user files​

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

Adjust permissions if needed:

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

6. Start the services​

systemctl start unicorn
systemctl start sidekiq

7. Verification​

  • Sign in to Mawidabp with a known user.
  • Open a recent review and check that the attached working papers open correctly (if PDFs do not open, it is usually permissions on the private directory).
  • Check the logs in /var/log/mawidabp/ for any errors during startup.

Create a read-only user​

For external reports or BI tools, it is sometimes useful to create a PostgreSQL user with read-only permissions.

  1. Log in as postgres:
cd /
su - postgres
  1. Enter the PostgreSQL client:
psql
  1. Create the user and grant permissions:
CREATE USER auditoria WITH ENCRYPTED PASSWORD '<strong-password>';
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. Test the connection:
psql -U auditoria -d mawidabp_production

With this, the user can read all tables but cannot modify or delete anything.

danger

Do not reuse the example password (123asd). Use a strong password, different from the main user, and store it in a secret manager.

  • Frequency: daily database dump, daily or weekly backup of private/. Depending on daily change volume, incrementals for private/ can save space.
  • Retention: 7 days on-site, 30 days off-site. Some regulations may require yearly retention.
  • Verification: restore the most recent backup on a staging server monthly. A backup that is never tested may be corrupt without anyone knowing.
  • Encryption: if the backups leave the data center, encrypt the file (openssl or gpg) before uploading.

Support​

If the restore fails or you want to review the backup strategy, write to soporte@mawidabp.com.