Single Source & Multiple Destinations

[ttshivers]

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]

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]

what's your usecase for this?

[rjycnfynby]

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

[ttshivers]

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]

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]

does it work for you?

[ttshivers]

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:

• Created the local backup job: # btrfs-sxbackup init /source /dest
  • Renamed the source container directory: # mv /source/.sxbackup /source/.sxbackup-local
  • Changed a line in the source container config file /source/.sxbackup-local/.btrfs-sxbackup
    • source-container = .sxbackup-local/
  • Changed a line in the destination config file /dest/.btrfs-sxbackup:
    • source-container = .sxbackup-local/
  • Ran the local backup job: # btrfs-sxbackup run /source
• Created the remote backup job: # btrfs-sxbackup init /source ssh://[email protected]:/dest
  • Renamed the source container directory: # mv /source/.sxbackup /source/.sxbackup-remote
  • Added 2 lines in the source container config file /source/.sxbackup-remote/.btrfs-sxbackup
    • source = /source
    • source-container = .sxbackup-local/
  • Added 2 lines in the destination config file ssh://[email protected]:/dest/.btrfs-sxbackup:
    • source = ssh://[email protected]:/source
    • source-container = /source/.sxbackup-remote/
    • destination = /dest
  • Ran the remote backup job: # btrfs-sxbackup run ssh://[email protected]:/dest

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]

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..