Set up automated backups to Quake AI

In this walkthrough, you build a complete backup pipeline that copies your project files to Quake AI object storage on a schedule. By the end, you will have rclone configured as a Quake AI remote, an encrypted backup repository powered by restic, a cron job running daily backups, and a tested restore procedure that proves your backups work.

What you will learn:

• Why off-site backups matter and how the 3-2-1 rule protects your data
• How to install and configure rclone to work with Quake AI's S3-compatible storage
• How to run your first backup and verify the files arrived
• How restic adds encryption and deduplication on top of object storage
• How to schedule automatic daily backups with cron
• How to restore files from a backup: the step most backup guides skip

Time estimate: 30–40 minutes

Prerequisites#

You need:

• A Quake AI account with S3 credentials: complete the object storage tutorial if you have not created credentials yet
• A Linux or macOS machine (the machine you want to back up)
• A directory with files worth backing up: your home projects folder, a code repository, or configuration files all work well

Why off-site backups#

Every backup strategy starts with the same question: what happens if your primary storage disappears? A disk fails, a laptop is stolen, a cloud provider has an outage, or you accidentally run rm -rf in the wrong directory. Local backups protect against some of these scenarios, but not all. If the backup lives on the same machine (or same provider) as the original, a single failure can take both copies.

The 3-2-1 rule is the industry standard: keep three copies of your data, on two different storage media, with one copy off-site. Quake AI object storage serves as the off-site copy. Your data is stored redundantly across Quake AI's infrastructure, separate from whatever machine or provider holds the original.

Step 1: Create a backup bucket#

You need a dedicated container (bucket) on Quake AI to hold your backups. If you completed the object storage tutorial, you already know how this works. Create a separate bucket for backups to keep them isolated from other data.

aws s3 mb s3://my-backups --profile rumble

If you have not configured the rumble CLI profile yet, follow Step 2 of the object storage tutorial first.

Verify the bucket exists:

aws s3 ls --profile rumble

You should see my-backups in the list.

Step 2: install rclone#

rclone is a command-line tool that syncs files between your local machine and cloud storage providers. It supports over 70 backends, including S3-compatible services like Quake AI. Use rclone instead of the AWS CLI for backups because it handles incremental transfers, bandwidth limits, and retry logic without extra configuration.

macOS:

brew install rclone

Linux:

curl -fsSL https://rclone.org/install.sh | sudo bash

Verify the installation:

rclone version

You should see version 1.65 or later.

Step 3: Configure the Quake AI remote#

rclone uses named remotes to store connection details. Create a remote called rumble that points to your Quake AI object storage.

Edit the rclone configuration file:

mkdir -p ~/.config/rclone
nano ~/.config/rclone/rclone.conf

Add the following block, replacing the placeholder values with your S3 credentials and region endpoint:

[quakeai]
type = s3
provider = Ceph
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY
endpoint = object.us-east-1.rumble.cloud
acl = private

Save the file. The block you pasted contains your plaintext Quake AI S3 secret key, and a default Linux file mode leaves the config world-readable to other local accounts. Lock the file down:

chmod 600 ~/.config/rclone/rclone.conf

Verify the connection:

rclone lsd quakeai:

This lists your buckets. You should see my-backups in the output. If you get an authentication error, double-check that the access key and secret key match what you created in the Quake AI console.

Step 4: Run your first backup#

Pick a directory to back up. This tutorial uses ~/projects; replace it with whatever directory holds files you care about.

rclone copy ~/projects quakeai:my-backups/projects \
  --transfers 8 \
  --progress

What each flag does:

• copy uploads files from source to destination without deleting anything at the destination. This is safer than sync for backups because a local deletion does not propagate to your backup.
• --transfers 8 runs 8 parallel uploads for speed.
• --progress shows real-time transfer statistics.

When the command completes, verify the files arrived:

rclone ls quakeai:my-backups/projects | head -20

You should see your project files listed with their sizes. Compare the count:

echo "Local files: $(find ~/projects -type f | wc -l)"
echo "Remote files: $(rclone ls quakeai:my-backups/projects | wc -l)"

If the counts match, your first backup is complete.

Step 5: Add encryption with restic#

rclone copies files in plain text. If your backups contain credentials, configuration files, or anything sensitive, encrypt them before they leave your machine. restic is a backup tool that encrypts and deduplicates data before uploading, using rclone as the transport layer.

Install restic:

macOS:

brew install restic

Linux:

sudo apt install -y restic

Initialize a restic repository on your Quake AI bucket. restic asks you to set a password: this password encrypts all backup data. Store it somewhere safe. If you lose it, the backups are unrecoverable.

restic -r rclone:quakeai:my-backups/restic-repo init

restic creates an encrypted repository structure inside the restic-repo prefix in your bucket.

Run an encrypted backup:

restic -r rclone:quakeai:my-backups/restic-repo backup ~/projects \
  --exclude-file ~/.config/rclone/backup-exclude.txt

restic reports how many files it processed, the new data uploaded, and the total repository size. The first backup uploads everything; subsequent backups upload only changed blocks, which is typically much faster.

List your backup snapshots:

restic -r rclone:quakeai:my-backups/restic-repo snapshots

Each snapshot is a point-in-time copy of your data. You can restore to any snapshot individually.

Step 6: Schedule automatic backups#

A backup you have to remember to run is a backup you will forget to run. Use cron to schedule daily backups at 2:00 AM.

Create a backup script:

cat > ~/backup-to-rumble.sh << 'SCRIPT'
#!/bin/bash
set -euo pipefail

LOG_FILE="$HOME/.local/log/rumble-backup.log"
mkdir -p "$(dirname "$LOG_FILE")"

echo "=== Backup started: $(date -Iseconds) ===" >> "$LOG_FILE"

restic -r rclone:quakeai:my-backups/restic-repo backup ~/projects \
  --exclude-file "$HOME/.config/rclone/backup-exclude.txt" \
  >> "$LOG_FILE" 2>&1

restic -r rclone:quakeai:my-backups/restic-repo forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune \
  >> "$LOG_FILE" 2>&1

echo "=== Backup finished: $(date -Iseconds) ===" >> "$LOG_FILE"
SCRIPT

chmod +x ~/backup-to-rumble.sh

The script does two things: runs a backup, then prunes old snapshots using a retention policy that keeps the last 7 daily, 4 weekly, and 6 monthly snapshots. This prevents unbounded storage growth while maintaining a useful history.

Set the restic password as an environment variable so cron can access it without a prompt. Create a password file:

echo "YOUR_RESTIC_PASSWORD" > ~/.config/restic/password
chmod 600 ~/.config/restic/password

Update the script to use the password file by adding this line after set -euo pipefail:

export RESTIC_PASSWORD_FILE="$HOME/.config/restic/password"

Add the cron job:

crontab -e

Add this line:

0 2 * * * /bin/bash $HOME/backup-to-rumble.sh

This runs the backup script every day at 2:00 AM. Check the log file the next morning to confirm it ran:

tail -20 ~/.local/log/rumble-backup.log

Step 7: Test a restore#

A backup you have never restored is a backup you cannot trust. Test the restore process now, while everything is fresh, rather than discovering problems during an emergency.

Create a temporary directory and restore the latest snapshot:

mkdir -p /tmp/restore-test

restic -r rclone:quakeai:my-backups/restic-repo restore latest \
  --target /tmp/restore-test

restic prints a summary when it finishes:

restoring snapshot 1a2b3c4d of [/home/alex/projects] at 2026-06-04 02:00:14 UTC by alex@workstation to /tmp/restore-test
Summary: Restored 42 files/dirs (12.480 MiB) in 0:03

restic restores files preserving their original absolute path under the --target directory. The summary line shows that path in brackets. Because you backed up ~/projects, the restored copy lands at /tmp/restore-test$HOME/projects (for example /tmp/restore-test/home/alex/projects), not /tmp/restore-test/projects.

Verify the restored files match the originals by pointing diff at that path:

diff -rq ~/projects "/tmp/restore-test$HOME/projects"

If diff prints nothing, the restored files are identical to the originals and your backup-and-restore cycle works end to end. If it reports differences, check whether they come from files that changed between the backup and the restore (expected) or from files that were excluded or corrupted (investigate).

Clean up the test:

rm -rf /tmp/restore-test

What you learned#

In this walkthrough, you:

• Created a dedicated backup bucket on Quake AI object storage
• Installed and configured rclone as the transport layer to Quake AI's S3-compatible endpoint
• Ran a plain-text backup with rclone copy and verified the file counts match
• Added encryption and deduplication with restic, so sensitive files are protected before they leave your machine
• Scheduled daily backups with cron and a retention policy that balances history against storage cost
• Tested a full restore to prove the backups are recoverable data, not inert bytes in a bucket

Your backup pipeline is now running. The restic repository grows incrementally: only changed blocks are uploaded each day, so storage costs stay proportional to your actual data changes, not your total data size.

Next steps#

• How to back up and restore a Quake AI VM: snapshot-based VM recovery on the platform
• How to schedule volume snapshots and restore data: Cinder snapshot schedules for attached volumes
• Migrate from AWS S3 to Quake AI: move your production S3 data to Quake AI
• Back up to Quake AI: the how-to reference with additional patterns (database backups, systemd timers, monitoring)
• Object storage pricing: understand the cost of your backup storage
• S3 feature compatibility: what S3 features Quake AI supports and what it does not

Clean up#

If you are done experimenting and want to remove the backup infrastructure:

Remove the cron job:

crontab -e

Delete the line containing backup-to-rumble.sh.

Delete the restic repository and backup bucket:

rclone purge quakeai:my-backups

Remove local configuration:

rm ~/backup-to-rumble.sh
rm ~/.config/restic/password

The bucket and all its contents are permanently deleted. No charges accrue after deletion.