-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for remote locations (via ssh) #7
Comments
I implemented github.com/helinwang/sync_mv that supports remote syncing. |
I highly recommend switching to BorgBackup, which is a production-ready tool built for remote syncing with minimal duplication. |
@alexandervlpl Correct me if I'm wrong, but I've looked at the docs a bit and I don't see any way to sync directory structures between two machines using Borg Backup. Is this possible, if one disables de-duplication, encryption, compression, etc. to actually replicate files on the target device which can be accessed outside the backup program? |
As far as I know, you can backup a directory structure to a backup repository located on another machine. So no direct sync to a directory structure. However, you can restore or mount the backup repository afterward. This would allow to finally recreate the same directory structure on the other machine. But this is indeed not the same as directly syncing two directory structures. PS: I actually prefer Kopia over Borg as a backup solution. I find it more intuitive and maybe it is a little bit more modern. Though, it basically has a very similar command line interface. PS2: For direct remote syncing two directory structures with deduplication, there is still syncthing. But with this you really need to do some set up steps and it is not just like a simple rsync command via ssh. |
@michael-ts if you need a usable mirror on the other side, Borg (or Kopia?) may work but it won't be ideal. Yes, you'll need to mount the backup on the second machine. AFAIK this is read-only. Also since this will be a FUSE filesystem and there's all this deduplication magic happening in the background, performance will probably be slow. You do want the deduplication though, that's what prevents all the extra useless copying we want to avoid. |
Did anyone try syncthing yet for such a usecase? Using a backup tool instead of rsync seems like a "misuse" of tools. Even though it might work, goals are different. |
Syncthing to me is more of a "Dropbox, but decentral and open source" use-case and in fact, I do not want it to happen continuously, because sometimes I can mess up my primary copy and want to use the "backup" - if you don't keep a "history" on the backup side, continuous sync sounds not like the right solution. |
I thought synching might have a one-sync mode which only runs one. But that does not exist. |
You can mount remote file system using sshfs and then use rsync-sidekick like normal on local file system. |
@MOJNICK Technically yes, but it's worth noting that sshfs is super slow even with simple file operations in ideal conditions on a LAN. Something like rsync-sidekick will probably be unusable unless you're working with a very small number of files. |
@alexandervlpl That's true. |
I would love to just use rsync-sidekick, but apparently this is restricted for cases where source and destination directory are local.
It would be extremely useful if it would support remote source or target. In the meantime, I created a little script (tailored to my needs) that does what I want (if I knew Go or would be interested in learning it, I would of course have just contributed to rsync-sidekick).
If someone is looking for something like that but with remote support, see here for some infos and here for the gist and adapt it to your needs.
I am currently not interested in working it out more than that, so would be happy if rsync-sidekick would subsume all the features so I can abandon my weekend project script for good.
The text was updated successfully, but these errors were encountered: