Restore from B2 with no local database

Hi Duplicati folks!

Arch Linux 5.19.13-arch1-1
Duplicati - 2.0.6.104_canary_2022-06-15

I have lost my local database but can successfully connect to my Backblaze B2 bucket. I’ve got two options that I need guidance with and hope you can help. Note that I’m now working on a new PC with a fresh installation of Duplicati and my files restored from a local backup (but not the Duplicati database).

  1. Try to restore the database (and any other files) from the B2 backup. This fails.

I’m getting the error Failed to Connect. No filesets found on remote target. My situation appears to be very similar to this post but in my case, I do not have any backup jobs in the web UI. My reading of the discussion indicates that Duplicati should try to regenerate the local database but this does not appear to be happening in my case.

  1. Configure Duplicati to take over/inherit the B2 backup.

I’m not sure if this is even possible, or desirable. If I create a new backup with identical settings to the original backup, will Duplicati detect the existence of files in the remote location and just upload the difference, or will I inadvertently destroy the remote backup by overwriting it?

The worst case scenario is that I delete the remote bucket and start the backup from scratch, but I would prefer to avoid having up upload several 100s of Gb again.

Thanks for reading this far.

How? The other did a Direct restore from backup files which builds a partial temporary database.

If the goal is to get a permanent database back, you would recreate the job (ideally from a saved
Export To File) and run database Repair (because Recreate button is unavailable without a DB).

Neither way can work unless that folder has files with dlist in their names. You could try looking.
If you see a folder with many dblock and dindex files, there should be some dlist there as well.

Pointing to a bucket or folder that’s wrong for the backup could cause failure to find those filesets.

Thanks for your reply, @ts678. You’ve highlighted my lack of clarity in what I want to achieve and also my ignorance about the specifics of how duplicati works.

I was attempting a direct restore from backup files, as per the instructions you linked to. Naively, I thought there may be some trace of the database file there that I could restore but my backups are locally encrypted before being uploaded to B2 so all I could see was generically-named backup files. I don’t need or want to restore everything from backup so have given up on the idea of recovering the database in this way.

My second question still stands though. What are my options for connecting to (“inheriting”) the B2 remote backup now that I have restored the files locally?

Thanks for your help.

Could you please clarify that as requested? Do some file names have dlist in them?
If so, you might be telling Duplicati to look in a different spot, where there is no backup.

The database file isn’t there, but is rebuilt (ideally) from just the dlist and dindex files.

In exceptional cases of missing blocks, Duplicati might have to search the dblock files.
This could be a large download, and the last 90% of the progress bar can get very slow.
If things go normally, you get to 70% on the progress bar, and have your database back.

How stale is the other backup you restored, and does it have a (could be dangerous) stale database in it?
The database describes the destination and it needs to match. If it’s close, it might be possible to change destination to match database, but this is technically complicated and risks losing backup, which typically would be very bad, but since you got some or all of your files back, you’d just be losing the old file history.

Safer plan was given:

If that doesn’t fit, please explain. There are also unanswered questions about the files you see in B2.

Browsing the files in my B2 bucket from the Backblaze web UI, I see multiple files with what look like two naming conventions: .dlist.zip.aes and .dindex.zip.aes (examples below). I am confident that the file destination is correct.

duplicati-20210927T130000Z.dlist.zip.aes
duplicati-ic60410fe84064e7db27f09565d2c137a.dindex.zip.aes

You make a good point about the freshness of the restored files versus the freshness of any recovered database. I’d been having trouble with Duplicati for a couple of weeks … the backup settings had disappeared, which happens occasionally for me after a system update in which case I follow these instructions to get them back. That did not work this time and this prompted me to make a full local backup prior to wiping my PC and building it anew.

I now have the situation where the remote backup files are a couple of weeks older than the freshly restored files that I now seek to backup. This might be a showstopper in terms of “inheriting” the remote backup. The more I think about it, the more I think it is probably a bad idea to pursue this course of action and should just start a new backup from scratch.

I hope I have answered the neglected questions. I’m leaning towards starting a new backup bucket unless you feel there is a better way to proceed.

Thanks again for your detailed responses to my post.

If there aren’t any with dblock in the name, then you have no backup data. A dindex indexes a dblock.
I don’t see a way to change the Backblaze web UI sort order, but it looks to be alphabetically by name.
What this means is that the dlist files show up in backup order (based on date), then dblocks show:

image

What happened in those weeks? It’s not age itself, but doing Duplicati backups. Check the screenshot example above to see whether you were able to upload any dlist files newer than the local backup as

which sounds like it was frozen some weeks ago, and if Duplicati is also frozen then, things still match.
Depending on how you did the local backup, you might see your old database. Check its timestamp too.
Its date would ideally be around the date of the latest dlist, so just copy it into the Local database path.
Hit the Verify files button to see if the database and destination line up as well as hoped. If so, done.

If you prefer to start from scratch and lose old file versions, that’s fine too. If you prefer to debug, fine too.
It would be useful to see what files Duplicati is actually seeing in its list. at Job → Show log → Remote.
That can be done after a Recreate, or Repair if Recreate is dimmed out due to no database in existence.

Here’s one saying No filelists found on the remote destination after a Recreate without a dlist:

Click the list line to expand, then if you like you can copy and paste into notepad or something to search.

I have created a B2 snapshot of my bucket and downloaded it (slowly, hence the delay in responding to this thread). I’m having trouble locating the Duplicati database among the recovered files.

I choose Restore from the Duplicati GUI and point it to my local unzipped snapshot, then enter my encryption key. I can see all my backed up files, across various date ranges. The most recent backup is early September which corresponds roughly with when Duplicati stopped working for me.

I was only backing up the contents of my home/ folder and there’s nothing obvious among the few hidden directories and dotfiles. Searching for ‘duplicati’ retrieves nothing. Where would you expect to see the database? Until I can find it, I cannot Verify, Recreate or Repair.

I’m not getting answers to my questions. This path might be going far off track.

Did you really “make a full local backup” of entire PC? If so, that saved the DB.
Look in your C:\Users\<you>\AppData\Local\Duplicati if you can do that.
Job DB is random-letters.sqlite. Even better is if you got Duplicati-server.sqlite.

Next, did Duplicati run during or since above backup? That will make DB stale.
You would then not download the files yourself. Duplicati would do that for you.

Do you now see that you have such file types? We can use them, but it’s harder.
You might also have needlessly paid Backblaze for the big dblock file downloads.

Or do you think you have any databases in your full backup that you can just use?

EDIT:

I forgot this was Linux. Check .config/Duplicati folder in home directories for you, root, duplicati.
I’d note this is becoming circular. OP says you lost the local database, but is it actually somewhere?
The details of the full local backup aren’t given, so I don’t know how easy it is to search for file name.

Usually an Arch system moves away from its config somehow, but the config is still on the machine.
https://aur.archlinux.org/packages/duplicati-latest also says look at /var/lib/duplicati/.config
They also had a type EnvironemntFile for awhile, and I don’t know exactly what that would break…

If you have a searchable full backup, please search. If no DB anywhere, then we’ll run a DB recreate.

Thanks for the EDIT. Yes, I’m running Linux.

My “full” backup is of my home/ directory only, so not as full as that term might imply. There is no ~/.config/Duplicati folder among the backup files, and the backup does not contain directories for Duplicati or root users. There are no other files except those in the /home/my-user-id/ folder hierarchy.

I think it’s safe to say that there is no Duplicati database in the B2 bucket. With the benefit of hindsight, I would also have included the directory that contained the duplicati database had I known about its importance when I set up the backup. I’ve made a note for myself to do this!

I confirm that the B2 bucket contains both dlist and dindex files. These are also now stored locally after I downloaded the snapshot.

Thank you for your detailed help, and patience. :slight_smile:

err, no. Backuping the backup database is not supposed to be useful, because it will most probably be stale.
The way to go is to export the job, recreate it with the new computer, and then recreate the database from the backup.

Thanks @gpatel-fr … duly noted!

Thanks for that update. Situation is clearer now. You’ll have to recreate the local database.

meaning:

You didn’t save Export and didn’t save any database, but you can manually add job as best you can.
After that, click job on home page, click Database, look at Local database path to see where it is.

Wherever Arch put them is what you could save if you want to avoid having to recreate backup data.
After saving, don’t run Duplicati until you’re back, so destination and its database will remain in sync.

Push buttons.

image

If you’re doing this from scratch, only the Repair button would be enabled (blue). If you’ve tried some
things that didn’t work, then there might be a wrong database, so Recreate (delete and repair).

If backup data is missing, Duplicati will have to download dblock files, so if you want to reduce costs
(which will be small dlist and dindex files, and maybe large dblock files), you can create or edit job to
point to the local folder of your full B2 download. You would make database and move job back to B2.

If you already have a B2 job, clear the B2 Application ID and B2 Application Key before changing to a
Local folder or drive, as those options don’t apply. If you leave them, it’s just a warning though.

Thanks for listing the next steps.

I have now recreated the database but have two warnings and two errors (details below).

It seems that there are/were two missing remote files. What are the implications of this? Do I need to worry, or do I just keep backup of my files as normal from now on?

Thanks.


Warning 1
2022-10-13 20:05:30 +01 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Found 2 missing volumes; attempting to replace blocks from existing volumes

Warning 2
2022-10-13 20:06:57 +01 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Found 2 missing volumes; attempting to replace blocks from existing volumes

Error 1
2022-10-13 19:38:29 +01 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b7ff25facac5848928e51843cb4dd5189.dblock.zip.aes by duplicati-i7298cbbcece04682a58c00fa02ce0e73.dindex.zip.aes, but not found in list, registering a missing remote file

Error 2
2022-10-13 19:52:19 +01 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b4a796c48308d4bbd8da62a9ded947400.dblock.zip.aes by duplicati-iba5060b7fc3748e0adda3adad8cb8771.dindex.zip.aes, but not found in list, registering a missing remote file

Full error log

            {
  "MainOperation": "Repair",
  "RecreateDatabaseResults": {
    "MainOperation": "Repair",
    "ParsedResult": "Success",
    "Version": "2.0.6.104 (2.0.6.104_canary_2022-06-15)",
    "EndTime": "2022-10-13T19:07:28.97846Z",
    "BeginTime": "2022-10-13T18:11:10.458261Z",
    "Duration": "00:56:18.5201990",
    "MessagesActualLength": 0,
    "WarningsActualLength": 0,
    "ErrorsActualLength": 0,
    "Messages": null,
    "Warnings": null,
    "Errors": null,
    "BackendStatistics": {
      "RemoteCalls": 3971,
      "BytesUploaded": 0,
      "BytesDownloaded": 369094106,
      "FilesUploaded": 0,
      "FilesDownloaded": 3970,
      "FilesDeleted": 0,
      "FoldersCreated": 0,
      "RetryAttempts": 0,
      "UnknownFileSize": 0,
      "UnknownFileCount": 0,
      "KnownFileCount": 0,
      "KnownFileSize": 0,
      "LastBackupDate": "0001-01-01T00:00:00",
      "BackupListCount": 0,
      "TotalQuotaSpace": 0,
      "FreeQuotaSpace": 0,
      "AssignedQuotaSpace": 0,
      "ReportedQuotaError": false,
      "ReportedQuotaWarning": false,
      "MainOperation": "Repair",
      "ParsedResult": "Success",
      "Version": "2.0.6.104 (2.0.6.104_canary_2022-06-15)",
      "EndTime": "0001-01-01T00:00:00",
      "BeginTime": "2022-10-13T18:11:10.396439Z",
      "Duration": "00:00:00",
      "MessagesActualLength": 0,
      "WarningsActualLength": 0,
      "ErrorsActualLength": 0,
      "Messages": null,
      "Warnings": null,
      "Errors": null
    }
  },
  "ParsedResult": "Error",
  "Version": "2.0.6.104 (2.0.6.104_canary_2022-06-15)",
  "EndTime": "2022-10-13T19:07:30.113479Z",
  "BeginTime": "2022-10-13T18:11:10.396435Z",
  "Duration": "00:56:19.7170440",
  "MessagesActualLength": 7948,
  "WarningsActualLength": 2,
  "ErrorsActualLength": 2,
  "Messages": [
    "2022-10-13 19:11:10 +01 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: The operation Repair has started",
    "2022-10-13 19:11:10 +01 - [Information-GetGpgProgramPath-gpg]: gpg",
    "2022-10-13 19:11:10 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Started:  ()",
    "2022-10-13 19:11:26 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Completed:  (7.73 KB)",
    "2022-10-13 19:12:28 +01 - [Information-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-RebuildStarted]: Rebuild database started, downloading 23 filelists",
    "2022-10-13 19:12:28 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20210927T130000Z.dlist.zip.aes (5.84 MB)",
    "2022-10-13 19:12:30 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20210927T130000Z.dlist.zip.aes (5.84 MB)",
    "2022-10-13 19:12:30 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20211103T133535Z.dlist.zip.aes (6.16 MB)",
    "2022-10-13 19:12:31 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20211103T133535Z.dlist.zip.aes (6.16 MB)",
    "2022-10-13 19:12:47 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20211208T085824Z.dlist.zip.aes (6.28 MB)",
    "2022-10-13 19:12:49 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20211208T085824Z.dlist.zip.aes (6.28 MB)",
    "2022-10-13 19:13:00 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20220110T130000Z.dlist.zip.aes (6.46 MB)",
    "2022-10-13 19:13:02 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20220110T130000Z.dlist.zip.aes (6.46 MB)",
    "2022-10-13 19:13:13 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20220217T130000Z.dlist.zip.aes (6.69 MB)",
    "2022-10-13 19:13:15 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20220217T130000Z.dlist.zip.aes (6.69 MB)",
    "2022-10-13 19:13:26 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20220307T083217Z.dlist.zip.aes (6.71 MB)",
    "2022-10-13 19:13:28 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20220307T083217Z.dlist.zip.aes (6.71 MB)",
    "2022-10-13 19:13:40 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20220322T130000Z.dlist.zip.aes (6.79 MB)",
    "2022-10-13 19:13:42 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-20220322T130000Z.dlist.zip.aes (6.79 MB)",
    "2022-10-13 19:13:53 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-20220508T193128Z.dlist.zip.aes (7.06 MB)"
  ],
  "Warnings": [
    "2022-10-13 20:05:30 +01 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Found 2 missing volumes; attempting to replace blocks from existing volumes",
    "2022-10-13 20:06:57 +01 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Found 2 missing volumes; attempting to replace blocks from existing volumes"
  ],
  "Errors": [
    "2022-10-13 19:38:29 +01 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b7ff25facac5848928e51843cb4dd5189.dblock.zip.aes by duplicati-i7298cbbcece04682a58c00fa02ce0e73.dindex.zip.aes, but not found in list, registering a missing remote file",
    "2022-10-13 19:52:19 +01 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b4a796c48308d4bbd8da62a9ded947400.dblock.zip.aes by duplicati-iba5060b7fc3748e0adda3adad8cb8771.dindex.zip.aes, but not found in list, registering a missing remote file"
  ],
  "BackendStatistics": {
    "RemoteCalls": 3971,
    "BytesUploaded": 0,
    "BytesDownloaded": 369094106,
    "FilesUploaded": 0,
    "FilesDownloaded": 3970,
    "FilesDeleted": 0,
    "FoldersCreated": 0,
    "RetryAttempts": 0,
    "UnknownFileSize": 0,
    "UnknownFileCount": 0,
    "KnownFileCount": 0,
    "KnownFileSize": 0,
    "LastBackupDate": "0001-01-01T00:00:00",
    "BackupListCount": 0,
    "TotalQuotaSpace": 0,
    "FreeQuotaSpace": 0,
    "AssignedQuotaSpace": 0,
    "ReportedQuotaError": false,
    "ReportedQuotaWarning": false,
    "MainOperation": "Repair",
    "ParsedResult": "Success",
    "Version": "2.0.6.104 (2.0.6.104_canary_2022-06-15)",
    "EndTime": "0001-01-01T00:00:00",
    "BeginTime": "2022-10-13T18:11:10.396439Z",
    "Duration": "00:00:00",
    "MessagesActualLength": 0,
    "WarningsActualLength": 0,
    "ErrorsActualLength": 0,
    "Messages": null,
    "Warnings": null,
    "Errors": null
  }
}

It’s impossible to say without more data. A good case would be there are irrelevant leftover dindex files, referencing irrelevant dblock files. If lost dblock files are actually in use, then backup damage is present.

Recovering by purging files explains how to use list-broken-files. GUI Commandline is the simplest way.

If you prefer, you can post a link to a database bug report to get a manual inspection (or try one yourself).

List-broken-files did not show any errors, so I take this as a good sign.

I have now successfully backed up my local files to the B2 bucket, and all historical versions are still intact. There were no errors during upload and the files were verified without problem.

Thanks @ts678 for your patience and for guiding me through the process in such a careful and detailed way.

1 Like

A dindex whose associated dblock is missing is pretty useless, so can probably just be deleted.
If the missing dblock was a problem, I think list-broken-files would have flagged it as such.

If you want to test, you could either move the dindex or rename it to not begin with duplicati-.
That just hides it while keeping it around (just in case). A smooth DB recreation would be good.
Smooth would stop at 70% on the progress bar. Not-smooth would be past 90% and quite slow.
This was touched on earlier in terms of volume. Past 70% gets into downloading larger dblocks.

Remote file referenced … but not found in list, registering a missing remote file #4586
is an issue with similar symptom that was found by DB recreate for a restore without database.
Possibly yours has similar origins, but neither case has enough history saved for good tracking.