Use copy storage as primary storage

Support
, ,
#1

I had a look at different topics discussing backup copy and different storages, but i’m still not quite sure what i want to do is ok.

I have a setup with one storage on local disks and another storage on B2. Currently i have a schedule where i first copy to the local disks and then do a copy to B2.
This works fine but require me to be at home to do the backups.
Now i’m most of the time working outside, and it means that my backup only run when i’m back home, or even sometimes not at all.

So what i’d like to do is to use the B2 as a “primary” storage and backup directly to this storage, without going first to the local disks. That means that even when i’m at home, i won’t use the copy feature anymore of course (meaning 2 times the backup job on the source machine, but i’m ok with that).

I just want to be sure that i can just reconfigure my schedules, remove the copy job and start doing backups directly the same repositories to the B2, without losing any version and messing up the snapshots ?

#2

That should certainly work, but I would suggest still adding a copy job from local to B2 (not the other way around, because B2 egress is not free). If you do this, then you’ll be able to replace corrupt chunks on your local storage by copying over from your B2 storage.

If you take this setup, you should use different backup ids for local and B2 backups to avoid the conflicts before the copy job and the backup jobs.

#3

Thanks for the confirmation Gilbert.
I already use Erasure Coding on the local storage, so maybe the copy is redundant ?

If i understand correctly, backing up the same repository with 2 jobs (different backup ID) on same storage won’t double the B2 storage usage ?
Same for initial backup, as B2 already contain the repository data, the initial backup for the new job will only add changed data (uploading everything again would take a long time and is more difficult when i’m not home for a few days) ?

#4

Erasure Coding isn’t a guarantee that damaged files can always be recoverable.

More likely, the backup job and the copy job will share a large number of chunks. This is the benefit of lock-free deduplication, a distinctive feature of Duplicacy.