masc3d / btrfs-sxbackup

Incremental btrfs snapshot backups with push/pull support via SSH
GNU General Public License v2.0
117 stars 20 forks source link

Single Source & Multiple Destinations #9

Open ttshivers opened 9 years ago

ttshivers commented 9 years ago

When trying to use a single destination for multiple sources, the second time you initialize the same source for a new job, it returns the error "ERROR source is already initialized". Is there a way of using the same source for multiple backup jobs to different locations?

masc3d commented 9 years ago

not officially. you could amend your source containers manually to achieve this though (by renaming the source container .sxbackup to something else and changing the config file .btrfs-sxbackup on both source and destination accordingly)

masc3d commented 9 years ago

what's your usecase for this?

rjycnfynby commented 9 years ago

I think that it would be nice to have in case someone would need to make backups to a different physical locations.

ttshivers commented 9 years ago

I am trying to set up a local and offsite backup solution that operates on independent schedules/frequencies. Let's say for example, I might have daily local backups, but only weekly offsite backups. I have been using duplicity in the past, which supports this, but I have been getting much better performance with this method of btrfs snapshotting.

masc3d commented 9 years ago

ok. I will consider re-introducing the customization of source container names. until then you can rename them manually. I would suggest to keep the naming with .sxbackup- as a prefix eg: .sxbackup-offsite .sxbackup-local as this will probably be the naming scheme I will follow when adding this.

if you have more questions let me know..

masc3d commented 9 years ago

does it work for you?

ttshivers commented 9 years ago

I was able to get it working, but I had to do a few more things than just renaming the source container. This is what I did:

This method does work, but it is very cumbersome and annoying. One thing that bothers me is that I have to trade ssh keys two ways (source <-> remote) because when I run the remote job, it connects back through ssh to my local computer to run the backup. Its adding this additional SSH connection that seems totally unnecessary.

masc3d commented 9 years ago

yes, renaming the source and editing the config file, two steps as mentioned. takes like 10 seconds, I don't really see how that's cumbersome, even though it's a manual process admittedly.

you wouldn't need to have two backup jobs to have both push and pull though, except you really want to keep them entirely separate. if you have suggestions how to avoid two way authentication in this case I would be pleased to hear them..