=> 🏡 Home | Back to notes

Server & database backups

Last updated on 10 December 2022

I run a number of services on my own machines and VPSs, and for each system I ensure there are appropriate backups in place.

Backup target

I usually use Backblaze B2 [1] as a backup solution due to its low costs, simplicity, and ease of use.

=> 1

Linode's Object Storage service [2] is also great, but I use Linode to handle nearly 100% of my workloads and it feels safer (and more compliant with the 3-2-1 principle of backing-up) to store backups with a different datacentre and provider from the primary data store.

=> 2

Depending on the type of system, my backup strategy is slightly different. This note documents my approaches for different type of systems.

Note: I use Docker to run all of my services. As such I prefer Docker approaches to backup too.

Filesystem backups

These types of backups take snapshots of a particular directory (e.g. the user's home directory). I use Restic [3] to create snapshots of the backup directory at handy intervals.

=> 3

I created and maintain a Docker image [4] for this, which can be easily run with the following docker-compose.yml file.

=> 4

version: '2'

services:
  serverbackup:
    image: wilw/fs-backup
    restart: always
    volumes:
      - /home/user:/backupdir
    environment:
      - B2_ACCOUNT_ID=changeme
      - B2_ACCOUNT_KEY=changeme
      - RESTIC_REPOSITORY=b2:bucket-name
      - RESTIC_PASSWORD=complexstring
      - RESTIC_HOSTNAME=hostname

This backs-up snapshots every hour to the target repo, and auto-prunes old backups.

View the project home [5] for more information on the setup and configuration.

=> 5

MongoDB backups

My MongoDB backups take a database dump each hour, and ships them to the target Restic endpoint (in my case, B2). There is a Docker repo [6] for this image.

=> 6

For this, use it in a docker-compose.yml like the following:

version: '2'

services:
  dbbackup:
    image: wilw/db-backup
    restart: always
    environment:
      - MONGO_HOST=dbhost
      - MONGO_USERNAME=dbusername
      - MONGO_PASSWORD=dbpassword
      - MONGO_AUTH_DB=admin
      - MONGO_DBS=db1;db2;db3
      - B2_ACCOUNT_ID=changeme
      - B2_ACCOUNT_KEY=changeme
      - RESTIC_REPOSITORY=b2:bucket-name
      - RESTIC_PASSWORD=complexstring
      - RESTIC_HOSTNAME=hostname

For more information on what the container does, read the project README [7].

=> 7

Optional: auto expire DB backups

Given this backup strategy does not auto-prune old backups (like the Restic-based ones do), a lifecycle policy can be useful to auto-expire objects after a number of days.

Below is an example lifecycle policy, which auto-expires files with the backups/ prefix after 30 days. It can be deployed using s3cmd (e.g. s3cmd setlifecycle lifecycle_policy.xml s3://bucket_name).

  
    auto-expire-backups
    
      backups/
    
    Enabled
    
      30
    
  

Note: on B2 this can also be accomplished through the web UI.

Note on auto-expire

Since moving DB backups to Restic too, there is no longer any need for this lifecycle policy.

Photos backup

For info on how I backup my photos, see the Photoprism [8] note.

=> 8

=> Back to notes