You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature you'd like to have.
The ability to replicate via rdiff-backup. This is our current backup method, but as we move more products to k8s, it has gotten harder to pull off. We started investigating writing an operator to take a snapshot and use rdiff-backup (or perhaps use SnapScheduler in combination with a more simple cron job), but then we discovered VolSync, which is almost a perfect fit except for this lack of support. Instead of building our own, I'd be happy to contribute this support to VolSync, but I wanted to first log an issue and gauge interest.
What is the value to the end user? (why is it a priority?)
rdiff-backup is a reverse incremental backup tool that uses the rsync protocol. It's not really suitable for replication, to be clear, but a way to take space-efficient backups. It generally works over SSH.
How will we know we have a good solution? (acceptance criteria)
A new replication method that looks a bit like the current rsync SSH method, something like the following:
@kyrofa I've discussed with @JohnStrunk and think we would potentially be interested in this if you're willing to contribute and help maintain the mover. Copying some comments John had from a request for a kopia mover:
By the end of the process, we need to have:
Mover code (controller + mover parts)
Documentation
Tests
Since this will be a fairly substantial piece, starting w/ a design PR is probably a good place to begin.
We'd have a few questions at the start:
Do you envision this as a backup/restore operation similar to the way restic works?
I.e. a replicationsource that connects via ssh to an existing rdiff server somewhere to backup
then a replicationdestination that would restore from that same server?
Or is this going to be more of a point-to-point connection like rsync/rsync-tls where you have a source that connects to a destination started by volsync? In this case, do you ever plan on using rdiff restore functionality or would it just be assumed your destination pvc contains the latest files + the extra metadata from rdiff?
Additionally if you're looking into this route, I'd recommend you look at rsync-tls as a reference, as the old rsync ssh method will most likely get deprecated soon.
Describe the feature you'd like to have.
The ability to replicate via rdiff-backup. This is our current backup method, but as we move more products to k8s, it has gotten harder to pull off. We started investigating writing an operator to take a snapshot and use rdiff-backup (or perhaps use SnapScheduler in combination with a more simple cron job), but then we discovered VolSync, which is almost a perfect fit except for this lack of support. Instead of building our own, I'd be happy to contribute this support to VolSync, but I wanted to first log an issue and gauge interest.
What is the value to the end user? (why is it a priority?)
rdiff-backup is a reverse incremental backup tool that uses the rsync protocol. It's not really suitable for replication, to be clear, but a way to take space-efficient backups. It generally works over SSH.
How will we know we have a good solution? (acceptance criteria)
A new replication method that looks a bit like the current rsync SSH method, something like the following:
The text was updated successfully, but these errors were encountered: