Published: 05.10.2026
BorgBackup, usually called Borg, creates backups that are compressed, encrypted and deduplicated. Deduplication means that identical data is stored only once, so repeated backups take much less space than full copies. Cloud Drive supports Borg as one of its access methods. This article gives a simple routine, with placeholders for the connection details shown in your customer area.
Concepts you need
- Repository: the folder on the remote storage where Borg keeps all of its backup data.
- Archive: one backup run stored inside the repository, with its own name and date.
- Passphrase: the secret that protects the repository. Without it, the data cannot be read.
- Deduplication: reuse of identical chunks between archives, which saves space and traffic.
- Prune: the operation that deletes old archives according to rules you choose.
Install Borg and create the repository
On Debian and Ubuntu, install the borgbackup package with the package manager. Then create the repository with the borg init command and the encryption option set to repokey-blake2. The repository address has the form ssh://USER@HOST/PATH/TO/REPO, where you replace each capitalised word with the value from your customer area. If the connection details give a port, add it after the host name. Choose a strong passphrase and keep it in a password manager, because a lost passphrase makes the backups unreadable.
After creating the repository, export its key with the borg key export command and store the file in a second safe place, away from the server.
Create an archive
Run borg create with the stats option, then the repository address, two colons, an archive name and the folder to back up. The archive name should include the date, for example the word web followed by the date, so that each run has a unique name. Keep the list of folders explicit, and exclude caches or temporary folders that you do not need to keep.
Prune old archives
Use borg prune to keep a sensible number of archives, for example seven daily, four weekly and six monthly ones. Always test the rules first with the dry-run option, together with the list option. Borg then shows what would be deleted and changes nothing. Run prune only after a new backup has finished successfully.
Check and restore
Run borg list on the repository to see its archives, and borg info on one archive to see its size and deduplication statistics. Test a restore regularly. Create an empty folder, change into it, and extract one file with borg extract, using the archive address and the path of the file inside the archive. Compare the result with the original. Occasionally run borg check on the repository to verify its integrity.
A simple nightly routine
- A script started from cron creates an archive with the date in its name every night.
- The same script runs prune with your rules after each successful backup.
- The script writes its output to a log file, which you read weekly.
- Once a month, restore one file into a test folder and compare it.
Scripts need the passphrase too. Store it in a file that only the backup user can read, and let Borg read it through the BORG_PASSCOMMAND setting, rather than writing it into the script itself.
Frequently asked questions
Why use Borg instead of copying files? Borg keeps a history of archives, encrypts the data and sends only new chunks, which suits backups that repeat often.
Can Borg back up a database? Borg backs up files, so dump the database to a file first, using the database's own dump tool, and then back up the folder that holds the dump.
What if I lose the passphrase? The data cannot be decrypted without it. Keep the passphrase and the exported key in safe places, separate from the server.
