File Recipe

Backup files and directories

This recipe shows how to back up files and directories with a tar command that writes to STDOUT. The Backup Verified agent reads that stream, encrypts it locally, uploads the encrypted backup, and lets you download and decrypt it later.

View Recipe Decrypt & Restore

What this recipe is for

This recipe is a practical way to protect application files, uploads, configuration directories, shared folders, or other groups of files you care about. It works well when the data you want to protect lives on disk and can be archived with tar.

Unlike the simpler “current directory” recipe, this one is meant for situations where you want to target specific paths directly. That makes it a better fit for servers, application environments, and structured file backups where you already know which directories matter.

The workflow is still straightforward: create a tar archive on STDOUT, let the agent encrypt it locally, and upload only the encrypted result to Backup Verified Managed Storage.

Good fit for

Application directories
User uploads and shared files
Configuration snapshots
Server-side file backups

Not ideal for

Large databases that need native dump tools
Disk images or full bare-metal restore workflows

Before you begin

Install the Backup Verified agent.
Create or obtain your bv-agent.yml config.
Make sure your config includes a valid agent_key and client_encryption_key_b64.
Know exactly which directories you want to include and which ones you want to exclude.

Why this works

The command below writes the tar archive to STDOUT instead of creating a local archive file first. The agent reads that stream directly, encrypts it locally, and uploads only the encrypted result.

That gives you a simple and efficient workflow for file backups without needing to manage an intermediate tar file on disk.

The recipe

Use tar to archive the directories you want, exclude the ones you do not, and keep the archive on STDOUT for the agent.

Example command

tar -cf - \
  --exclude='./tmp' \
  --exclude='./cache' \
  /var/www /etc

Replace the paths and excludes with ones that make sense for your environment.

Key detail: Write to STDOUT

tar -cf - /path/to/data

The trailing - after -cf tells tar to write the archive to STDOUT. That is what the agent expects.

Suggested BV config

This example shows a targeted file-and-directory backup using tar and explicit paths.

# 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: "files_backup"
  name: "Files and Directories Backup"
  description: "Archive selected directories via tar"
  delete_after_days: 0

source:
  type: "tar"
  backup_command: >
    tar -cf -
    --exclude='./tmp'
    --exclude='./cache'
    /var/www /etc

The > after backup_command: is YAML formatting for multi-line text. It is not shell output redirection.

How to run it

bv-agent validate-config -config bv-agent.yml
bv-agent backup -config bv-agent.yml

Validate first, then run the backup. If the tar command succeeds and the upload completes, the encrypted backup should appear in your portal.

What success looks like

The agent completes without error.
Your backup appears in the Backup Verified portal.
You can later download the encrypted file and decrypt it locally.
The decrypted output contains the files and directories you intended to protect.

What could go wrong

File backups are simple in concept, but a few common mistakes can still trip you up.

Wrong paths

A typo in a path or excluding the wrong directory can leave out data you meant to protect.

Archiving too much

If you point tar at overly broad paths, you may capture more data than intended and create larger backups than necessary.

Assuming success without testing recovery

Confidence grows when you actually download, decrypt, and inspect a real backup instead of assuming it is fine.

Backup Verified helps you move from “I ran a command” to “I know my encrypted backup exists and I can recover it.”

How to download it later

1. Sign in to your Backup Verified portal.
2. Open the backup entry you want.
3. Use the download option to retrieve the encrypted backup file.
4. Save it to a location on your machine where you want to perform the decrypt step.

What you download is still encrypted. That is expected.

Why that matters

The backup is stored encrypted. Backup Verified never needs your decrypted files in order to store them.

Decryption happens locally with your own key material, which keeps control and privacy where they belong.

How to decrypt it locally

Once you have downloaded the encrypted backup file, use the agent to decrypt it locally.

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

Replace backup.bin.enc with your actual downloaded filename. The --out path is where the decrypted result will be written.

Then inspect the output

ls -lah ./restore/

Verify that the restored files and directories are where you expect them to be.

Good habit

Do at least one real download-and-decrypt test early. It is one of the fastest ways to build real confidence in your setup.

What restore means for this recipe

In this recipe, restore usually means recovering the archived files and directories to a local folder, inspecting them, and then copying them back to the destination you need.

Because file backups vary by environment, the restore target may also vary. Many people restore into a temporary location first, verify the contents, and then move files into place in a controlled way.

Related recipes

When you are ready, these are natural next steps.

All recipes