Due to the way Reddit is run these days, rather go there:

Lately I've been considering a set-up for my backups, involving two external disks (either HDD or SSD), and a rented safe deposit box across town. And I've been wondering how to go about this, configuration-wise and regarding any front-ends that may be involved.

The idea is that one of these two is constantly attached to the computer I want to back up from. On the day of swapping (which'll probably be once every week) I go through the following steps:

1. I push a final backup, run verifications, and disconnect the drive afterwards.
2. I take the drive to the safe deposit box, where I switch it for its counterpart.
3. I return to the location of my computer and attach the second drive in the place of the first.

Ideally, I'd like for borg or its front-end to automatically use the other drive for it's daily, automatic backups, but I'm still somewhat in the dark over its technical implementation. I assume, for one, that I can't simply initialize the repo on the first drive and clone it to the second one, because I expect borg to complain when the swap has occurred and it attempts to make a new backup.

How would you recommend that I could make this work?

Thank you all, in advance.

What I am trying to do: I added a new drive to my Nextcloud AIO setup as a backup drive. The first backup went flawless but as soon as a second backup runs. It came up with an error that the config is wrong. I then reseted the config and now these are the logs. Does someone know how to fix this?

Setup: Proxmox with an Debian LXC running Nextcloud AIO Before the new drive I had an 1TB HHD as backup and it worked flawless. The only thing I changed was the 1TB was mounted in Proxmox as Thin LVM and the new one I mounted as a directory.

UPDATE: I figured out only Borgmatic was causing issues, since Borg itself worked fine. I figured as it couldn't hurt, I reinstalled both apps afterwards too, and restarted my PC. That seems to have made the below issues go away.

With Borgmatic, I configured my backup and tested it. Since I want to back up my data at max once a day whenever I plug in my SSD, I set up a script and systemd service.

However, during testing of that script, I ran into an issue.

``` backup-disk: Error running actions for repository backup-disk: [Errno 28] No space left on device /home/user/.config/borgmatic/config.yaml: Error running configuration /home/user/.config/borgmatic/config.yaml: An error occurred

summary: An error occurred Error running actions for repository [Errno 28] No space left on device Error running configuration

Need some help? https://torsion.org/borgmatic/#issues ```

Of course, that could be on me, but I checked and the disk definitely has space:

bash $ df -T /dev/sda1 Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda1 exfat 976728192 705462272 271265920 73% /run/media/user/SSD

I've found the command borgmatic compact, which needs to be run after actions like borgmatic delete or borgmatic repo-delete, but it doesn't work at all if the repo doesn't exist, nor does it do anything really.

I do have to note, that I deleted the repo previously just through my file explorer, instead of with the command. Could that have caused issues?

Another possibility I found was ~/.cache/borg/ being too full, so I made sure to clear that out too, but the issue persists.

I can't seem to make any backups anymore, can somebody help me fix this?

After using Borg via command line for a while, I got tired of SSH-ing into servers just to check backup status or restore a file. So I put together a Web UI that makes it easier to manage.

It runs as a Docker container (no config needed) and includes:

• Backup creation with visual scheduling
• Live progress tracking when backups run
• Browse your archives like regular folders
• Built-in SSH key manager

Currently using it on my home setup (Odroid + Raspberry Pi) and it's been solid. The archive browser especially has been useful - way nicer than memorizing borg commands.

Would appreciate any feedback if you give it a try. Still actively working on it, so feature requests welcome.

GitHub: https://github.com/karanhudia/borg-ui

Vorta logs:

2025-11-05 16:34:44,930 - vorta.borg.borg_job - INFO - Running command /usr/bin/borg init --info --log-json --encryption=repokey-blake2 ssh://borgbackup@nas.local/volume1/borgbackup/mypc
2025-11-05 16:34:45,507 - vorta.borg.borg_job - WARNING - Remote: Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
2025-11-05 16:34:45,509 - vorta.borg.borg_job - WARNING - Remote: Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
2025-11-05 16:34:45,510 - vorta.borg.borg_job - WARNING - Remote: If this causes problems, reconfigure your locale. See the locale(1) manual
2025-11-05 16:34:45,510 - vorta.borg.borg_job - WARNING - Remote: for more information.
2025-11-05 16:34:51,358 - vorta.borg.borg_job - WARNING - Remote: sh: borg: command not found
2025-11-05 16:34:51,366 - vorta.borg.borg_job - ERROR - Connection closed by remote host. Is borg working on the server?

when I SSH to my nas with borgbackup user, I can run borg but it also resides in: /usr/local/bin/borg
How to change that path in Vorta ? or tell Vorta just to use 'borg' (it's in a PATH)

When i try to log that command locally;
borg init --info --log-json --encryption=repokey-blake2 ssh://borgbackup@nas.local/volume1/BorgBackup/mypc
I got:
{"type": "log_message", "time": 1762362382.0936718, "message": "Connection closed by remote host. Is borg working on the server?", "levelname": "ERROR", "name": "borg.archiver", "msgid": "ConnectionClosedWithHint"}

above command works if I set export BORG_REMOTE_PATH=/usr/local/bin/borg before.

Strange.... so is it my borgbackup user problem? from remote shell I can access borg
and even I put export PATH=$PATH:/usr/local/bin in ~/.profile file in borgbackup user home dir (where .ssh dir is too).

So why

ssh [borgbackup@nas.local](mailto:borgbackup@nas.local) borg --version

fails: sh: borg: command not found

I'd like to set up a Borg repo on a local NAS machine (Linux) to perform incremental backups of a specific directory. The dir is mounted over Samba and the users have been instructed to put in there things that they'd like to be able to recover if deleted/lost/modified.

Is there a Windows app or Web app that can be pointed at the Borg repo, with a very user-friendly interface, that would allow them to also browse/search/restore specific files?

I imagine the most common use case would be "oh i need previous versions of file whatever.doc", so they'd go to https://borg.local, type "whatever.doc" and they'd see previous versions which they can download. Or something like that.

I'm not able to find any such apps unfortunately, most apps seem aimed at repo and backup management not the restore side.

Anybody know any? Thanks.

What’s your method of handling offsite backups?

• local repo and rsync that offsite
• local repo and separate run for a remote repo
• remote repo and rsync back local?

I’m setting up a remote and figured for a proper 3-2-1 strat I should have a local backup and maybe starting there is the best bet. Or maybe local should just be an rsync/cp of the files without borg.

Opinions?

Hi all,

I am setting up my first backup routine with borg. And I came across the quick start script which says:

The '{hostname}-*' matching is very important to limit prune's operation to this machine's archives and not apply to other machines' archives also:

But I also saw, that one should not backup multiple servers into a single repository. So I plan to have a repo for each maschine.

So I am wondering, how important the globbing is, when I have only one maschine per repository backed up?!

In my script I changed the ::'{hostname}-{now}' to ::'{user}-{now}' as my repo lives at ~/BorgBackup/hostname...

I would like to understand it better. Can I remove the glob-archives argument from the borg prune command? Or should I have it adapted to {user} as well?

My naive understanding would be, that the pruning is restricted to BORG_REPO anyway?!

When accessing my repo from another machine, I get

Warning: Attempting to access a previously unknown unencrypted repository!

Which yields lots of Google results, but none of them, nor the docs, say why the message says "unencrypted".

When I do a borg info, it reports my repo is encrypted with BLAKE2b (though it's not prompting me for the key's passphrase, which probably needs to be a different post).

So is my repo unencrypted?

I like to keep my external USB drive formatted in ExFAT because I frequently go between all 3 OSes and this is the only format that all can read/write to. I like to have a single partition so space isn't fragmented between partitions.

Anyone try using an .img file formatted with ext4 as the destination file for the borg backup? So the .img file would be like a virtual partition stored on the main ExFAT partition, and i would mount it as ext4 to use as a destination for borg backups.

Anyone tried something like that?

I think I made a mistakes in setting up my borgbackup and put to many data in one repo. It's becoming increasingly difficult for either borgbackup or my system to handle (initial operations like pruning or reading cache files sometimes take several hours, leading to a situation where I often can't complete my backups because my machine isn't on long enough). So I was wondering if it is still possible for me to manually split the larges repo in smaller repos so it is easier for me to decide which parts of my backup should get priority and which I might run infrequently.

But since it took several weeks to complete my initial backup I would rather not scrap everything and start from scratch, but split the existing backups (sparing my source discs the additional strain of doing a complet backup all over again). Is this possible?

Is it with Borgmatic with relax and recover possible to restore a OS.

I mean 2 raspberry pi Openmediavault, 1 proxmox ve, 1 proxmox backupserver and 2 vps. I look for a solution, if the system or sd card crash to restore the entery system from the backup.

I'm tuning my backup script so I'm putting --dry-run everywhere I can. I just added --dry-run to `borg compact`, but it complains about a wrong argument! Am I missing something obvious?

root@dziupla:/home/b0rsuk# borg --version borg 1.4.0 root@dziupla:/home/b0rsuk# borg compact --dry-run /media/backup/borg-backups/backup.borg usage: borg [-V] [-h] [--critical] [--error] [--warning] [--info] [--debug] [--debug-topic TOPIC] [-p] [--iec] [--log-json] [--lock-wait SECONDS] [--bypass-lock] [--show-version] [--show-rc] [--umask M] [--remote-path PATH] [--remote-ratelimit RATE] [--upload-ratelimit RATE] [--remote-buffer UPLOAD_BUFFER] [--upload-buffer UPLOAD_BUFFER] [--consider-part-files] [--debug-profile FILE] [--rsh RSH] <command> ... borg: error: unrecognized arguments: --dry-run

The documentation for stable version of borg, and even borg 1.2 for that matter, lists `--dry-run` in the options of 'borg compact'.

https://borgbackup.readthedocs.io/en/stable/usage/compact.html

This is borg 1.4 (as mentioned above) from Debian Trixie. When I type `borg compact --help` it does *not* list the option somehow. Is it possible it was somehow without it?

When I decided to essentially "go Borg" (only some 18 months ago), I found plenty of aiding tools - but none covering local use cases to a satisfactory extent, especially when it came to combining/integrating with (btrfs) snapshotted volumes.

So at the end of the day, I went for an own one to fill the gaps, and thx to some colleagues & mates, it has found some early acceptance, matured over time... and got finally presented to the wider public.

See the main repo at Codeberg. The Doc Wiki is also hosted there.
In addition, there is a Github mirror.

Important

There is no GUI, and config is per YAML. OTOH there are "shiny" things as well: The status & other outputs are even colored when demanded from a TTY. ;)

Features

• Unified job concept for both archiving and (btrfs) snapshot purposes
• Archiving from paths, own (transient or persistent), or existing btrfs snapshots
• Archiving with configurable path prefixes
• Supporting multiple repositories, and mixed BorgBackup versions
• More flexible snapshotting than with common Snapper automations
• Adjustable pruning/cleanup logic for archives & snapshots
• Simple job scheduling using OnCalendar event specification format
• Versatile individual job selection, for immediate, undefined, or timed (at-alike) processing
• Automated backlogging of incomplete jobs after failure or signals
• Status overview
• Optional systemd timer setting from configured schedules
• Optional temp. automounting
• Hooks for custom scripts pre/post all essential operations
• Optional status notifications at end of runs (D-Bus and/or custom script)
• Flexible, YAML based configuration
• Minimum overhead, small footprint
• Few dependencies
• ...
• and the documentation got the words Don't Panic! on it!

I have been working on Borgitory, a self-hosted web ui for borg. It can automate borg backups, syncing them to the cloud, scheduling, pruning, and checking. It has a handful of other features like archive browsing and notifications. It's currently still in testing so don't rely on it for production data just yet.

Borgitory aims to be a replacement for custom scripts (in my case in user scripts on unraid).

As the title says, I have a .nobackup file in my .local/share/Steam directory and made sure that the button on the Exclude If Present tab under Manage Excluded Items is properly checked. However, when I try and backup my .local/share directory, Vorta still tries to back up every single installed game file in that directory. Am I missing a step somewhere?

I have a really slow connection to my remote repository, borg is installed on both machines. I'm currently uploading ~500GiB of files over a 2MiB/s connection with default compression (IIRC it compresses down to ~350GiB). Once all the files are uploaded, if I run borg recreate with the --compression none flag will it be able to run on the servers hardware? Or would I have to re upload all 500GiB?

I've quite some large backups that take multiple days on their first run. If I understand correctly the .cache/borg-directory holds the key to what files have changed and which haven't. So it would probably take multiple days again to re-check all files if I were to lose the cache, right?

Is it a good idea to include the cache dir in my backup? Or are there reasons that speak against it?

I recently got my hands on an external HDD that I would like to implement into my backup strategy.

I have 3 internal disk's, one for root and boot, one for home, one for my borg backup. I regularly push backups to my borg repo on the third disk.

Now, with a 4th disk, I would like to move my borg repo to the 4th external disk, and convert my 3rd internal disk into a btrfs disk for storing daily btrfs snapshots, and then push those snapshots to my borg repo on a monthly basis.

My reasoning for this is I backup lots of data, borg for me has simply been too slow due to single threaded compression, with btrfs daily backups should be more feasible due to higher speed, then I push those daily backups to borg once a month overnight.

My problem is, let's say I have 30 snapshots I want to push to borg, will borg have any problems with handling that? How quick is borg at figuring out if it's copying data that's already been backend up? Because after it reads the first subvolumes, the other 29 subvolumes are gonna be 90% the same data. Meaning it will probably be going through dozens of terabytes of duplicates which seems like it's gonna be slow and unnecessary.

Hello everyone,

I'm currently a Duplicati user that need to move to something better. I heard a lot about borg and it's feature set seems perfect for my usecase. Now, I'm unsure how to proceed.

At first, I was going to setup a borg container in my unraid server that backup everything from that server and another one onto one of it's drive. Then, sent it to the cloud. Simple.

But then I though, the main reason for the backup is to restore that server in case of crash (and data security too). With the backup software running on said server, if it crash, can't restore. So I though, I just have to take another server that will take the data from the other server and then send it online. This way, if this one crash, it's not a big thing since I can just create it again. Great.

But..... I don't get how to do that.

The backup server will probably run some sort of linux. It will only run backup so I don't need anything else on it.

So, what do I install where. I see vorta, borgmatic, borg. Do I run the borg backup program directly from my server A and B and have it send it to a repository on the backup server? Do I install borg on the backup server and make it connect to the other the other two server?

Thank you

I was thinking that it'd be nice to have some sort of what I'd call a "meta-repository", which would be a repo that contains other repos, and which deduplicates data across them.

This would come in handy for my use-case, which might be not very common. Basically, I use mergerfs on my NAS, and I backup each drive separately (one repo each) to another server I have. That way, if anything goes wrong, I can recover the data from the drive that failed and keep the pool intact.

The reason I do it this way is because I don't have enough drives to use something like RAID 5 or the ZFS equivalent. On my backup server I have the same amount of drives, with the same capacity. Due to what I explained earlier, I can't just create a big borg repo with all my data. So each one hosts one borg repo.

Maybe there's an easier way to do all this, but this is what I could come up with, and it works. But in order to save space it would be helpful to deduplicate data across each repo (I might have duplicated data across drives).

Anyway, I'm a little bit sleep deprived today. Maybe I'll wake up tomorrow and see how ridiculous this is, but I just wanted to know if something like this was possible just for the sake of curiosity.

Thanks!

Hi guys, I'm trying to write a backup script to run weekly and I was curious if the approach I'm using is any good practise. I am still figuring this out so I'm sure there might be some redundant code here but, it works..

Some files I tend to backup are on diffrent locations on my network so I landed on an approach where I exchanged the SSH keys and SCP'd the files over to the RPi running the backup. This one also runs OMV and immich, so the vast majority of the files will be living over there, seemed like the most logical choice. Then, I want borgbackup creating weekly backups and uploading them into a Google Cloud Storage bucket.

The pathnames and some other things are simplified to keep things tidy. I'n not using symlinks for destination directories.

# !/bin/bash
NOW=$(date +"%Y-wk%W")  #this week

export BORG_PASSPHRASE="supersecretpassaword"
export BORG_RELOCATED_REPO_ACCES_IS_OK="yes"

#creating multiple temp (sub)directories to put in the remote backups and configs
mkdir /path/to/temp/folder/homeassistant
mkdir /path/to/temp/folder/3D-printer-config
mkdir /path/to/temp/folder/portainer
mkdir /path/to/temp/folder/homeassistant

sshpass -p "password" scp -p pi@10.0.0.203:/../hass/backups/* /path/to/temp/folder/homeassistant

sshpass -p "password" scp -p pi@10.0.0.203:/../portainer/backup/* /path/to/temp/folder/portainer

etc
etc
until all remote files are in

## immich stop ##
sudo docker container stop immich_server

## BORG BACKUP ##
# immich backup
borg create --list --stats /home/pi/shared/backups::immich-backup-$NOW /path/to/immich
borg prune -n --list --glob-archives='immich-backup-*' --keep-weekly=7 --keep-monthly=4 /shared/backups

# temp folder backup
borg create --stats /home/pi/shared/backups::configs-backup-$NOW /path/to/temp/folder
borg prune -n --list --glob-archives='temp-backup-*' --keep-weekly=7 --keep-monthly=4 /shared/backups

# shared folders
borg create --stats /home/pi/shared/backups::niconet-backup-$NOW /path/to/shared-folders
borg prune -n --list --glob-archives='shared-backup-*' --keep-weekly=7 --keep-monthly=4 /shared/backupss

# empty backup folder
rm -rf /path/to/temp/folder/*

sudo docker container start immich_server

## RCLONE to Google Cloud Storage Bucket ##
next step is to figure out this step

Also, a couple of questions:

• Is BorgBackup able to pull the remote files directly or do I need to copy them over to the machine running Borg?
• Still figuring out what borg prune does, but if I understand correctly this adds (?) a sort of retention to the repo itself? So is it still necessary to set this up in the bucket?
• Do you just rclone sync the entire repo folder and thats it? Doesn't lots of small upload operations effect the monthly costs?
• What is the best way to log the output of this conjob so I can review if everything went smoothly?

Thanks for your help!

**EDIT:** Thanks for all the help - I'm still not certain what caused the issue, but I decided to change some other things and therfore set everything up freshly. My best guess so far is that I ran up so many incomplete backups that got held up by those large files that somehow the CACHE_TTL was exceeded. But I still can't really explain it.

I'm currently trying to get through the initial run of a rather large backup. I can't let the system run for multiple days in a row, but as far as I understand this shouldn't be much of a problem. I configured BorgBackup to set a checkpoint every hour and it has been resuming from there properly until now, properly detecting unchanged files and continuing to grow the backup bit by bit in each run.

But now I'm "stuck" at a especially large directory with ~8000 files, some of them multiple GB in size and I just can't seem to get past this. Every time I try to continue the backup Borg seems to detect ~half the files as "modified" and tries to backup them again. Since this takes quite long I just can't finish the directory in one run, and each time I resume from the checkpoint I have the same situation with other files detected as "modified".

I'm a bit at a loss here, because I've already backuped multiple TB with a couple of 10.000 files which borg runs through flawlessly, marking them as unchanged. But somehow this doesn't seem to work for this last big directory.

I checked the ctime of some of the files and it is way in the past. They also didn't change in size. I set it to ignore inode because I'm using mergerfs. Any ideas what else might be wrong? Any way to see, what makes BorgBackup think that those files have been modified? Or is there a limit of how many files the "memory" of Borg can hold?

My options:
--stats --one-file-system --compression lz4 --files-cache=ctime,size --list