Feature request: Include remote Borg repos

[mnllrnz]

Summary

Borgitory’s cloud synchronization feature is a convenient way to mirror local Borg repositories to cloud storage via Rclone.
However, this approach introduces a serious risk: if the local repository becomes encrypted by ransomware or otherwise corrupted, those damaged files are synced to the cloud, overwriting the healthy backup copy.

To ensure true ransomware resilience, Borgitory should support direct remote Borg repositories instead of syncing local ones.

---

Problem

Currently, Borgitory users must choose between:

• Local repositories — fast and simple, but vulnerable if the server is encrypted.
• Synced repositories — mirrored to cloud storage, but risk propagating corruption or ransomware encryption.

Because Borgitory’s cloud sync copies the repository files themselves, ransomware can encrypt the local repo and cause those encrypted files to overwrite the clean cloud version during the next sync.

This defeats the purpose of having an off-site backup.

Borg’s own documentation discourages syncing or mirroring repositories for this reason:

“If you want redundant repositories, create them separately with borg init.”
— BorgBackup FAQ

---

Proposed Enhancement

• Add support for direct remote repositories (ssh://) so Borgitory can back up directly to the cloud instead of syncing a local repo.
• Optionally support append-only mode for immutable backups.
• Add a warning or note in the UI/docs explaining that the current Cloud Sync mirrors files and can propagate ransomware encryption.

---

Benefits

• Prevents ransomware or local corruption from affecting off-site backups.
• Aligns with Borg’s recommended practice of using independent repositories.
• Reduces dependency on Rclone mirroring and improves reliability.
• Strengthens Borgitory’s role as a safe, automated backup orchestrator.

---

References

• BorgBackup FAQ — Multiple Repositories
• 3-2-1 Backup Strategy (ISBA Whitepaper)

[mlapaglia]

sounds like a good idea. borgbackup only supports SSH for remote syncing, so we'd need a separate sync task specific to the borgbackup? we could also just have a separate entry in the cloud provider for borgbackup and follow special logic in that. borg's developer says using rclone is normal for cloud sync.

have a local borg repo and use rclone to have a copy in the cloud.

If attacker code gets control over your machine, storage does not need to be mounted to be affected, the attacker could also use borg to delete your backups or maybe intercept s3-related credentials and use them to delete all your s3 stuff.

[mnllrnz]

Thanks for reply. I think that comment should be understood in the context of S3 storage. As you know, there are cloud providers like Borgbase or Heztner that have storage plans tailored at Borg, where operations are done via SSH.

My suggestion would be to implement these as repositories, because that is what they are. Having a section for local repos and other one for remote repos. From there, we would use the the same backups and schedules menus for both of them.

[WasdeAsde]

@mnllrnz +1 could be a live saver! Positive in this case would be less storage usage on-prem too. (For multiple repos with different schedule/retention but same source)

It's still in testing and not stable, so not for production-use, but borg 2.x could be used for that functionality.
Borg 2.x anouncement

[marcnesium]

+1 waiting for this 💪