I managed to install BorgBackup on Debian and Zima OS, but I’m having trouble creating an SSH key on Debian (done) and, more importantly, transferring (copying) it to the BorgBackup on Zima OS.
Assuming your username is “user” and hostname is “computer”…
Create the key :`
ssh-keygen -t ed25519 -C "BorgBackup user@computer
This key is stored in /home/user/.ssh/id_ed25519.pub
And it is this key that you need to copy inside the Borg container’s " ~/.ssh/authorized_keys" file, you don’t need to create a Borg user on your host.
Like I said, just add Borg-ui to your docker stack, it will probably make it easier to manage this part of the setup
PS: don’t forget to use a different SSH port than your nas’s
Just wanted to add a bit of feedback here because this thread pushed me to test Borg properly on my ZimaCube.
I ended up setting up BorgBackup with borgmatic as the backup engine, and then added Borg UI as the dashboard layer. I have to say, I am really impressed.
What I like about this setup is that it is very clear what is happening:
Borg/borgmatic handles the actual encrypted backups
Borg UI gives a clean dashboard to view the repositories and archives
Repositories can be imported in “Observe Only” mode, so the UI can monitor and browse them without taking over the backup job
You can clearly see archive count, storage used, last backup, encryption type, and repository health
In my test I created separate repositories for different backup targets:
zimacube-appdatazimacube-brain
Both are encrypted Borg repositories, and both are visible in Borg UI in Observe Only mode.
The most important part for me was not just creating the backup, but actually testing restore. I created the repo, ran the backup, listed the archive, then restored files into a test folder to confirm the backup was real and usable.
That makes a big difference. A backup is only trusted once a restore has been tested.
I really like this setup. For my use case it feels much stronger and clearer than a basic backup button because I can see exactly:
what is backed upwhere it is storedhow large the archive iswhether the repo is encryptedwhether restore actually works
Borg UI also looks very nice. The dashboard makes it much easier to understand what is going on, especially for users who do not want to manage everything from terminal.
Thanks for pointing this out. I think Borg + borgmatic + Borg UI is a very good option for ZimaOS users who want a more serious backup setup.
If i understand correctly, you want to make a second copy of your backups (Borg backup server ?) onto your nas… If that’s the case you can simply setup a cron job using rsync.
Yes, you can setup as many backup servers as you want and manage them from a single borg-ui instance… Just not sure it’s worth the effort only to have a copy of your first backup
From the way I understand it, your current working setup is:
Your Debian PC runs Vorta/Borg
Your ZimaOS NAS stores the Borg repository on the HDD
The backup is pushed from the Debian PC to the NAS
That is actually a very good setup.
The important point is that the machine running the backup must be able to see/read the files being backed up. So if Borg is running inside a Docker container on ZimaOS, it can easily back up folders that exist on ZimaOS, but it cannot automatically see the files on your Debian PC unless you first expose/mount those Debian files to the NAS somehow.
So for backing up your Debian PC, I would keep Vorta on the Debian PC and let it push the backup to the ZimaOS NAS. That is the cleaner and simpler direction.
Then Borg UI on ZimaOS can still be useful as a dashboard layer. You can use it to view/monitor the Borg repository stored on the NAS, check archives, size, encryption, and restore testing, but I would not try to make the ZimaOS container “pull” the backup from the Debian PC unless you really want a more advanced setup.
So in simple terms:
Debian PC backup > best done from Debian PC using Vorta/Borg
ZimaOS NAS > best used as the backup storage target
Borg UI on ZimaOS > useful for viewing/managing the repositories
In my opinion, what you already have working with Vorta is probably the right foundation. The next important step is not changing the direction, but confirming that restore works from the NAS repository. A backup is only trusted once a restore has been tested.
Yes, from that Borg UI screen it does look possible.
The “Remote Machines” section is designed for exactly that type of setup. Borg UI can generate or import an SSH key, then use that key to connect to remote machines and manage them.
So there are two possible approaches:
Keep Vorta on the Debian PC and let it push backups to the ZimaOS NAS. Then Borg UI on ZimaOS can inspect the repository if that repository path is mounted into the Borg UI container.
Use Borg UI more directly by adding the Debian PC as a remote machine over SSH. In that case Borg UI needs an SSH key, and the Debian PC must allow that key to log in.
The screenshot below is showing the second method. It is asking you to create or import the SSH key that Borg UI will use for remote connections.
So yes, it appears possible, but the important things to confirm are:
Borg UI can SSH into the Debian PC
The correct folders on the Debian PC are exposed for backup
The Borg repository destination is on the ZimaOS storage
A test backup and test restore both work
Personally, I would still keep Vorta on the Debian PC if that is already working, because it is simpler. But Borg UI does appear to support the more centralised SSH-managed approach too.
