How to Back Up a Home Server With Borg, Restic, or Kopia

A home server stores files and settings you may not be able to replace after a disk failure, accidental deletion, or another loss. Borg, restic, and Kopia save encrypted backups, keep earlier versions, and avoid storing unchanged data again. A repository is the storage area a tool manages; each saved point in time is an archive in Borg and a snapshot in restic and Kopia.

Choose the tool whose destination and restore method you can manage: Borg suits an SSH-based, command-line setup; restic offers a consistent command-line approach across many storage types; Kopia adds a built-in graphical interface and policy-based scheduling. Whichever you choose, back up a separate copy of your recovery credentials, make changing databases consistent before saving them, and test a restore.

Decide what to save and where to put it

Start by listing the data and settings you need to bring services back. That might include user files, service configuration, application data, and database exports. Exclude replaceable caches or temporary files only after confirming that the backup will still contain everything needed for recovery.

A file-level backup can copy files used by a database, virtual machine, or container while they are changing. The copied files can then come from different moments, so they may not form one consistent state. Before backing up, use a service-appropriate method such as a database export, a filesystem snapshot, or a brief service shutdown. If you create a database export, check that the export command succeeded before backing up its output; a failed export should not pass silently into the backup job.

Put the repository somewhere separate from the server’s main storage. A second disk or network-attached storage protects against some local disk failures. But if the server can freely change that copy, it shares some risks with the server. An off-site copy adds protection against events that affect the whole home. Restic documents local, SFTP, REST, and cloud storage options; Kopia supports several destination types and provides a repository overview. Borg’s documented remote-host workflow uses SSH, as described in its Quick Start.

With deduplication, the tool stores repeated data once in the repository instead of writing another complete copy for every backup. Each tool stores data differently, so backup size, speed, and provider costs can vary from one tool to another. Test the chosen destination with your own data and connection.

Choose the workflow you can maintain

Borg, restic, and Kopia all support encrypted, versioned backups. Their day-to-day differences affect how you schedule jobs, keep older backups, and reclaim storage.

Choose Borg if you are comfortable with a command-line workflow and an SSH-accessible backup host. Borg calls each saved point an archive. Its routine has separate steps to create archives, remove old ones with prune, and reclaim space with compact. The example below follows Borg’s 1.4.x command style; confirm the encryption mode and options against the version you install.

export BORG_REPO=/path/to/backup-repository

# Initialize the repository once. Replace MODE with a supported mode.
borg init --encryption=MODE "$BORG_REPO"

# Create an archive of selected paths.
borg create --stats "$BORG_REPO"::'{hostname}-{now:%Y-%m-%dT%H:%M:%S}' \
  /etc /home /srv

# Example retention: keep selected daily, weekly, and monthly archives.
borg prune --glob-archives '{hostname}-*' \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 "$BORG_REPO"

# Reclaim space no longer needed by retained archives.
borg compact "$BORG_REPO"

The retention numbers are an example from Borg’s documentation, not a universal target. The archive-name filter helps keep a prune job focused on one host when several machines share a repository. Leave free space on the destination: Borg’s documentation warns that a full repository filesystem can make even archive deletion difficult.

Choose restic if you want a similar command-line workflow across local storage, SFTP, REST, and cloud destinations. Restic calls saved points snapshots. Set the repository location and password source where the scheduled job can access them, then initialize the repository once.

export RESTIC_REPOSITORY=/path/to/backup-repository
export RESTIC_PASSWORD_FILE=/path/to/protected-password-file

restic init
restic backup /etc /home /srv

# Inspect snapshots and test a restore to a temporary directory.
restic snapshots
restic restore latest --target /tmp/restore-test

# Example retention policy; prune reclaims data no longer referenced.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Restic’s backup documentation says the command can create a snapshot and still report that it could not read some source files. Exit status 3 indicates that some files could not be read, so configure an alert for this status. A snapshot can exist even though some files are missing. Restic also separates removing snapshots from reclaiming their data: forget removes snapshots from history, while prune reclaims data no longer needed. When restic prunes, it can lock the repository for a while. Schedule pruning so it does not block a backup you need to run.

Choose Kopia if you want a graphical interface, policy-based scheduling, or centralized management for multiple machines. In Kopia’s GUI, first connect to an existing repository or create one. Then select directories and set a policy for exclusions and retention. Set a snapshot frequency as well if you want automatic snapshots; a policy without a frequency does not schedule them. Kopia’s getting-started instructions show the setup flow and example retention settings.

Kopia runs quick maintenance about once an hour and full maintenance about every 24 hours by default, according to its maintenance documentation. Full maintenance removes unreferenced data and compacts repository storage. Monitor repository health and capacity even when maintenance runs automatically.

These workflows are illustrative. Before scheduling any of them, add the correct destination setup, exclusions, credential handling, error reporting, and service-specific steps for consistent data.

Keep credentials outside the server

The password or key required to access an encrypted repository is part of the recovery plan. If you lose the required secret, the backup tool cannot provide access to the data. Borg also recommends exporting a copy of its key. Store the necessary secrets somewhere recoverable that does not depend solely on the server being backed up.

For unattended backups, choose a secret-storage method the scheduled job can access and restrict access to that secret. Restic documents password files and environment variables for this purpose in its repository setup instructions. Do not put a password in a script that other local users can read. After setting up automation, verify that the job can access the secret without an interactive prompt.

Check backups and practice recovery

A successful job log alone does not prove that you can recover a service. Restore a representative file to a temporary directory, then test restoring the data or configuration needed by one service. Restic documents selective and full restores; Kopia also supports restoring snapshots and mounting them for access.

Repository checks provide different evidence from restore tests. A structure check examines the repository’s metadata and how its saved data is linked. A deeper content check reads the stored data. It takes more time and can incur retrieval costs when the data is stored remotely. Restic documents that restic check --read-data reads the repository’s data; Kopia’s verification documentation explains that its routine checks do not download, decrypt, and decompress every file. Kopia provides an option for deeper file verification.

Set a backup schedule based on how much recent data you can afford to lose. Then review job results and alerts, including warnings about unreadable files. Periodically test a restore and confirm that you can retrieve the password or key from its separate storage location. Those checks reveal problems that a scheduled job’s success message cannot.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com