Hi,
I have a storage backend that is damaged beyond repair. Now I need to change the target storage for all backup jobs. In the GUI, it seems I can neither change the storage backend of the Storage object nor the Storage settings of each Backup object.
Is there any other way available without having to re-create all Backup objects?
You can delete the storage and create a new one with the same name, but different destination.
Thank you @tangofan for the tip. However, I tried this already and in my case this did not work. The storage provider does not let me create a bucket with a name of a recently deleted one.
Also, the state of the storage (totally empty) would then be different from what my Storage object thinks to know about that state (tons of Gigabytes stored).
In fact, the first thing I tried after the damage was to run a check, and I also tried to re-run the backup tasks, but every action failed with an error message (saying that storage is not initialized).
So I definitely need to solve this at Duplicacy’s side. Deleting and re-creating all of my backup objects one by one only to change the storage destination is not a task I am really looking forward to. I am hoping for a faster way.
By “same name” I meant the same storage name in the Duplicacy Web UI. Just link to a different bucket (or even a different storage provider) in the storage definition.
Oh – sorry, a misunderstanding at my end.
So the connection between Backup object and Storage object happens by name, and not by some hidden ID?
I was thinking about replacing the Storage object but then I was not sure whether there is a unique object ID in the background that would prevent that replacement strategy.
So I’ll give it a try.
BTW, the damaged bucket still has a lot of files left. If I just leave them there, is there any chance they will be used for deduplication? Or would Duplicacy say, “hm, that’s not my data, I’ll leave it alone”?
(I am asking because reusing the old data would dramatically speed up the initial backup.)
I’m not sure what you’re trying to do. You said earlier that you want to back up into a different bucket. So in that case, no, the files in the damaged bucket are ignored. And more generally only chunks within the given storage are used for deduplication.
Sorry for not having been clear. Yes, the first plan was to use a different bucket. Then, based on your suggestion, I thought it might be a good idea to reuse the data that is already there, if technically possible. The point here is that the bucket itself got damaged through partially erasing files, but the files that are left should all still be intact. And at a total size of about half a terabyte, I would have saved a lot of time if the exiting chunks could have been reused.
However, in the meantime I tried to reuse the existing chunks but this failed. I created a new Storage that pointed to the bucket with the leftover chunks and ran a check, but the check said “missing chunks”, and the backups failed as well.
So I created a completely new, empty bucket and a new Storage, and now I am backing up everything from scratch. At least, I will have a new backup in a couple of days without tedious re-configuration. Thanks again tangofan for giving the initial tip!
You can actually reuse existing chunks by removing all files under the snapshots directory in the bucket. A new backup will then only upload chunks that do not exist in the bucket.