Backups

The following contains best practices for backups to an on prem deployment.

Microsoft SQL Databases

These are typically hosted on a Linux container but may also be hosted on an existing SQL Server instance.

Usual backup best practices apply such as scheduled daily backups. You may use SQL Server Management Studio (SSMS) or a third party tool to automate this.

These SQL databases contain the data that your users have uploaded to the system as well as most configurations and other data that the system stores.

PostgreSQL Vector

This is hosted on a Linux container.

The database includes the data uploaded in plain text format as well as a vector representation of it for faster searching.

Backups should be performed at the same time as the SQL backups as these databases reference each other’s content.

PostgreSQL Regular Backup Instructions Using pg_dump

1. Prerequisites

  • Install PostgreSQL Client Tools:

    # For Debian/Ubuntu sudo apt-get update sudo apt-get install postgresql-client # For CentOS/RHEL sudo yum install postgresql
  • Ensure Database Access:

    • The backup user must have read permissions on the target database.

2. Configure Password-less Authentication

  1. Create .pgpass File:

    touch ~/.pgpass chmod 600 ~/.pgpass
  2. Add Database Credentials:

    hostname:port:database:username:password

    Example:

3. Create Backup Script

Example Script (backup_postgres.sh):

  • Make Script Executable:

4. Schedule Backups with Cron

  1. Edit Crontab:

  2. Add Cron Job (Daily at 2 AM):

5. Verify Backups

  • Check Backup Directory:

    Ensure new .sql.gz files are appearing as scheduled.

  • Test a Backup Restoration:

    • Verify Data:

    • Remove Test Database:

6. Optional: Secure and Offsite Storage

  • Encrypt Backups (Using GPG):

  • Sync to Remote Server:

    Add to the backup script:

    • Ensure SSH keys are set up for password-less access.

7. Monitoring and Alerts

  • Check Logs Regularly:

    Review /path/to/backup.log for backup statuses.

  • Set Up Email Alerts:

    Ensure the script sends emails on failure as shown in the backup script.


Restoration Steps

  1. Create a New Database:

  2. Restore from Backup:

    • If Encrypted:

  3. Verify Restoration:

  4. Remove Test Database (if applicable):

 

Dashboard / Ingestor (Windows Server)

These servers don’t need regular backups as they don’t contain user information.

You may wish utilize server snapshots for disaster recovery.

Backing up the service directories before upgrades is recommended for easy rollbacks if required.

Configuration Backups

Windows Server

It’s recommended to backup the configuration files at these locations for easy reinstallation.

Dashboard: C:\inetpub\BGDDashboard\Configuration

Ingestor Service: C:\AGAT\BGService\Configuration

Paths may differ depending on installation choices.

Linux Server

The site specific configurations are stored in docker.env in the home or Gateway directory.

If modifications were made to the docker-compose.yml or docker-compose.override.yml files, these should be backed up too before upgrades.

The docker volumes contain database content and don’t need to be backed up if the databases have been backed up using the above methods. Other volumes contain models which will automatically be re-downloaded if required as well as application logs.

Â