Existing backup fails with "STORAGE_NOT_CONFIGURED"

Support
#1

This was an initial backup, which unfortunately got aborted due to an upstream ISP issue. I have some data in the bucket already, but now when I try to resume the backup I see this error in the log. I have verified that the config file does exist in the root - in fact it looks like there’s two copies - one hidden with 0 bytes and the other with 842 bytes.

An ideas on how I can initialize the storage again without starting this backup over again?

(trying to sanitize output since new users can only post 2 URLs).
“backup destination” is https://f002.backblazeb2.com

Running backup command from /cache/localhost/6 to back up /backuproot/data/media
Options: [-log -d backup -storage 2024-unraid-media -threads 30 -stats -stats]
2024-02-28 18:06:04.634 INFO REPOSITORY_SET Repository set to /backuproot/data/media
2024-02-28 18:06:04.634 INFO STORAGE_SET Storage set to b2://2024-unraid-media
2024-02-28 18:06:04.634 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_2024-UNRAID-MEDIA_B2_ID
2024-02-28 18:06:04.634 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_2024-UNRAID-MEDIA_B2_KEY
2024-02-28 18:06:04.735 INFO BACKBLAZE_URL Download URL is: <backup destination>
2024-02-28 18:06:04.825 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_2024-UNRAID-MEDIA_PASSWORD
2024-02-28 18:06:04.923 TRACE BACKBLAZE_CALL [0] URL request 'HEAD <backup destination>/file/<bucketname>config' returned status code 404
2024-02-28 18:06:04.923 DEBUG BACKBLAZE_LIST <backup destination>/file/2024-unraid-media/config did not return headers
2024-02-28 18:06:04.923 ERROR STORAGE_NOT_CONFIGURED The storage has not been initialized
The storage has not been initialized
#2

Which version of duplicacy CLi are you using?

Maybe this applies to your case too: File not found: how do I start from scratch? - #9 by gchen

#3

I’m on 3.2.3, so I don’t think it applies?

I’ve read that removing the config file from B2 is bad… So what about if I re-initialize the storage from Duplicacy? Not sure what impact that will have.

Thanks for checking!

#4

Is this a correct path to a config file?

Can you copy config file locally and verify that it is working (with a fake test repo)?

You will lose access to all previous versions.

#5

Yes, that’s the location of the config file. I can definitely copy it down to my computer, but since it’s encrypted, I can’t read it. Doesn’t the “fake” test repo need to be same name as the prior one? Like the config file is linked to it somehow?

#6

No, config file is independent, it contains encryption keys, and does not care where it is located.

You can just put a config file in a folder and add the location to duplicacy. If it recognizes it a a valid duplciacy datastore – your config file is OK, and the issue is specific to Backblaze somehow.

#7

You appear to be correct. I downloaded/deleted/re-uploaded the config file and it’s not failing now. It recognizes the previous backup was incomplete, so hoping this works…

2024-02-29 13:29:30.612 TRACE CONFIG_INFO File chunks are encrypted
2024-02-29 13:29:30.612 TRACE CONFIG_INFO Metadata chunks are encrypted
2024-02-29 13:29:30.613 DEBUG BACKUP_PARAMETERS top: /backuproot/data/media, quick: true, tag: 
2024-02-29 13:29:30.613 TRACE SNAPSHOT_DOWNLOAD_LATEST Downloading latest revision for snapshot unraid-media
2024-02-29 13:29:30.613 TRACE SNAPSHOT_LIST_REVISIONS Listing revisions for snapshot unraid-media
2024-02-29 13:29:30.643 INFO BACKUP_START No previous backup found
2024-02-29 13:29:32.222 INFO INCOMPLETE_LOAD Previous incomplete backup contains 31275 files and 4024291 chunks
2024-02-29 13:29:32.222 INFO BACKUP_LIST Listing all chunks
2024-02-29 13:29:32.222 TRACE LIST_FILES Listing chunks/
#8

Well, looks to be working. It’s estimated 6 days to complete and I think I can upload it again in under 3 days, but let’s see if it catches up.

#9

Wait, was this new storage location where you just started uploading into? Or was there supposed to be existing version history?

#10

Correct. As stated in my OP: “This was an initial backup, which unfortunately got aborted due to an upstream ISP issue. I have some data in the bucket already…”

#11

Ah, good. I missed that bit. Then it’s all good.

Still it’s unclear why did b2 behave this way. Network interruption should not have touched the config file – it’s written once and never touched since (only read)

#12

I’m not sure, but I have a guess. In the root of the B2 folder there were two ‘config’ files. Maybe the one Duplicacy was trying to access was the null one? Not sure, but I’m glad I was able to recover. Thanks for the tips!

#13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.