Automation Recipe

Run backups daily with cron

This recipe shows how to turn a working Backup Verified command into a repeatable daily task using cron. The goal is simple: stop relying on memory and make backups happen automatically.

View Recipe Decrypt & Restore

What this recipe is for

This recipe is for anyone who already has a working Backup Verified command and wants to run it automatically every day. It is the natural next step after proving that a manual backup works.

A scheduled backup is usually more valuable than a backup you plan to remember later. cron gives you a simple, proven way to run a command on a schedule without needing extra infrastructure.

The core idea is to keep the backup command itself stable and let cron handle when it runs. That keeps the workflow simple and easier to troubleshoot.

Good fit for

Daily backups of a known directory
Database backups with an already-tested config
Simple automation on a Mac or Linux server
“Set it and forget it” backup habits

Not ideal for

Untested backup commands you have never run manually
Highly complex orchestration that needs more than a single scheduled command

Before you begin

Install the Backup Verified agent.
Make sure you already have a working bv-agent.yml config.
Run at least one successful manual backup first.
Know the exact directory or environment where the backup command must run.

Why this works

Cron does not need to understand your backup. It only needs to run the right command at the right time.

That separation is useful: your Backup Verified config controls what gets backed up, while cron controls when it runs.

The recipe

Start with a working Backup Verified command, then schedule it with cron once per day.

Step 1: Confirm the manual command works

bv-agent validate-config -config /path/to/bv-agent.yml
bv-agent backup -config /path/to/bv-agent.yml

Do not automate first and debug later. Get one good manual run before adding a schedule.

Step 2: Add a cron entry

0 2 * * * cd /path/to/backup/source && /usr/local/bin/bv-agent backup -config /path/to/bv-agent.yml >> /path/to/bv-backup.log 2>&1

This example runs every day at 2:00 AM, changes into the correct directory first, and appends output to a log file.

Suggested BV config

Cron works best when the backup config is already stable and predictable. Here is a simple example using a tar-based directory backup.

# bv-agent.yml
bv:
  api_base: "https://backupverified.com"
  timeout_seconds: 30
  work_timeout_seconds: 0
  upload_timeout_seconds: 0

agent_key: "YOUR_AGENT_KEY"
client_encryption_key_b64: "YOUR_CLIENT_ENCRYPTION_KEY_B64"

backup:
  source_key: "daily_dir_backup"
  name: "Daily Directory Backup"
  description: "Scheduled daily backup via cron"
  delete_after_days: 0

source:
  type: "tar"
  backup_command: "tar -cf - ."

The same scheduling pattern can be used with MySQL, PostgreSQL, Docker volume, or other working recipes.

How to add the schedule

crontab -e

Open your user crontab, add the daily entry, save it, and let cron handle the schedule from there.

What success looks like

The job runs at the expected time each day.
The log file shows the command ran without obvious errors.
New backups appear in the Backup Verified portal on schedule.

What could go wrong

Most cron problems are not backup problems. They are environment and path problems.

Wrong working directory

Cron may run from a different default location than your shell. That is why the example explicitly uses cd /path/to/backup/source first.

Wrong binary path

Cron may not use the same PATH as your interactive shell. Use a full path to bv-agent if needed.

No logs, no visibility

If you do not capture output, a failed scheduled job can stay invisible longer than you would like.

The best automation is boring automation. Clear paths, a known working config, and basic logging go a long way.

Logging and sanity checks

A scheduled backup should leave behind some evidence that it ran. A simple log file is often enough.

tail -n 50 /path/to/bv-backup.log

Also check the portal from time to time. The schedule is only useful if new backups are actually showing up there.

How to download it later

1. Sign in to your Backup Verified portal.
2. Open one of the scheduled backups you want.
3. Use the download option to retrieve the encrypted backup file.
4. Save it locally for the decrypt step.

The download is still encrypted. That is expected.

Why that matters

Scheduling a backup does not change the privacy model. The uploaded backup is still encrypted before storage.

When you need the data later, you download the encrypted file and decrypt it locally with your own key material.

How to decrypt it locally

Once you have downloaded one of the scheduled backup files, use the agent to decrypt it locally.

bv-agent decrypt --in backup.bin.enc --out ./restore/ -config /path/to/bv-agent.yml

Replace backup.bin.enc with the downloaded filename.

Then inspect the output

ls -lah ./restore/

Confirm that the restored output looks like the data you expected to protect.

Good habit

Scheduled backups deserve occasional spot checks. Download and decrypt one from time to time so confidence stays grounded in reality.

What restore means for this recipe

Restore depends on what the scheduled job is backing up. If the scheduled job protects a directory, restore may mean recovering files to a local folder first. If it protects a database dump, restore may mean importing that decrypted dump into the appropriate database system.

The important thing here is that scheduling changes when the backup runs, not how recovery works. Download, decrypt, inspect, and then restore according to the underlying recipe.

Related recipes

These are the building blocks that pair well with a cron schedule.

All recipes