YunoHost Backups to External Storage: A Pragmatic Engineering Decision

The problem: a backup you have never restored is a guess

Your YunoHost server quietly holds mail, calendars, contact lists, and application data. The web admin panel makes it easy to click “Create backup” and move on. But a local archive sitting on the same disk as the server does not protect you from hardware failure, and an untested restore path does not protect you from a botched upgrade. The engineering decision is not whether to use YunoHost’s built-in backup system, but how to schedule it so that archives land on external storage and the restore path is proven.

This article treats YunoHost backup as a scriptable operations task. The thesis is simple: for a small Debian-based self-hosted server, the built-in backup tool is a pragmatic choice, but only if you automate the copy offsite and validate recovery before you need it.

What the built-in backup actually covers

YunoHost exposes backup functionality through both the web administration panel and the yunohost backup command-line interface. The backup scope generally includes system configuration, user accounts, mail data, and the data of installed applications. Because the CLI is scriptable, it is the better tool for scheduled operations.

Two interfaces matter here:

• Web admin: useful for one-off backups and for inspecting the configured backup location.
• CLI: useful for cron jobs, remote copy steps, and integration with external storage.

Behavior and available flags can differ between YunoHost versions, so treat any command below as a pattern to verify against your running release rather than a stable API.

The destination decision: local disk versus remote storage

YunoHost can write backup archives to a local directory or to remote locations such as SSH or FTP. The trade-off is operational simplicity versus failure isolation.

Destination	Strength	Risk
Local directory	Fast, no network dependency, easy to inspect	Shares fate with the server disk; a hardware failure can destroy both the live system and the backup
Remote SSH	Offsite copy survives local hardware loss; encrypted in transit	Requires SSH key authentication and network availability; slower for large archives
Remote FTP	Simple to configure on some storage hosts	Credentials and data traverse the network in cleartext unless the server explicitly adds encryption

For a single-server self-hosting setup, an SSH destination on a separate machine or NAS is usually the smallest change that meaningfully reduces risk.

Worked example: scheduling a weekly offsite copy

The following pattern creates a backup with the YunoHost CLI and copies it to a remote SSH destination on a schedule. Run all commands as root on the YunoHost server unless noted otherwise.

1. Confirm the CLI and flags

Before automating anything, verify the installed release supports the subcommands you expect.

yunohost backup --help

Expected check: the output lists subcommands such as create, list, and restore. If a flag you need is missing, consult the documentation for your installed version before proceeding.

2. Create a test backup manually

Generate one archive by hand and confirm it appears in the configured location.

yunohost backup create

Expected check: yunohost backup list shows the new archive, and the file size is non-zero. Large mail or database content can consume substantial temporary space and time during creation, so ensure the filesystem has headroom.

3. Copy the archive to external storage

Use rsync over SSH to move the archive offsite. Replace the placeholders with your actual paths and host.

rsync -avz <backup-directory>/<archive-name>.tar.gz \
  <user>@<remote-host>:/path/to/offsite/backups/

Risk: this requires passwordless SSH key authentication from the YunoHost server to the remote host. If the key is missing, the command will hang or fail. Test the rsync command interactively before adding it to cron.

4. Automate with cron

Edit the root crontab:

crontab -e

Add a line that creates a dated backup and copies it. Escape percent signs with backslashes because cron interprets them specially.

0 2 * * 0 /usr/bin/yunohost backup create --name weekly-$(date +\%Y\%m\%d) && rsync -a <backup-directory>/weekly-$(date +\%Y\%m\%d).tar.gz <user>@<remote-host>:/path/to/offsite/backups/

Expected check: after the scheduled window, confirm the archive exists on the remote host and that yunohost backup list on the server shows the matching local entry.

Rollback: to undo the schedule change, remove the line with crontab -e and delete the remote archive if it is no longer wanted.

The restore contract and its limits

Restoring an application backup generally reinstalls the app package and its data, but success depends on the app declaring compatible backup hooks in its YunoHost app manifest. Community-packaged apps sometimes lack complete backup/restore support, so a backup archive can exist without a reliable restore path.

Version compatibility is the second hard limit. Backups created on one YunoHost version may not restore cleanly on a significantly older or newer version. That makes the following check the most important part of the whole workflow:

1. Pick a low-risk application.
2. Create a test backup through the web admin or CLI.
3. Attempt a restore onto a spare YunoHost instance of the same major version.
4. Confirm the app and its data return to a usable state.

If the restore fails, the backup is not yet a recovery plan.

Actionable close

Do not enable a production schedule until you have restored a test archive to a spare instance. Start with one weekly cron job to an SSH destination, verify the remote copy appears, and document the restore steps you actually performed. YunoHost’s built-in backup is a reasonable foundation for a small self-hosted server, but the engineering value comes from the external destination and the proven restore path, not from the backup button itself.