How to test which database belongs to which job?

I just took a peek in one of my databases. Somewhere at the beginning of the file there is a section with (i think) last added or all filenames with paths in readable format.
If your backup sets differ in what files are backup’d - perhaps you can it distinguish this way? :wink:

Can we just appended those random characters to the name?

How did you take a peak? If this was on one of my Linux machines, I’d just use Adminer, but it’s my Windows computer. So I’m not very aware of what database tools exist for it.

I just brute-opend it in UltraEdit (on Windows). Not really a database viewer but hex will do :slight_smile:
I tried different dbs and could find at least some distinct filenames with paths. As i do have an job for each partition that i backup i can use this information.

sqlite%5D%20-%20UltraEdit%2064-bit

I use SQLiteBrowser on MacOS, which works very well. It looks like they have a windows version too.

It does all the stuff you’d expect of a DB browser.

2 Likes

@Pectojin: Even better! :slight_smile: They even have a portable version for Windows.

@jerrac: just open the database with this tool and have a look at the table “file”.
There are the backup’d files in plan text:

Hope that helps to identify the right database :slight_smile:

I used to work with MySQL through the MySQL Workbench, so I had to have a proper viewer :slight_smile:

But yep, good thinking. Looking in the files table should give some idea of what the database is for :slight_smile:

@cpo and @Pectojin, Thanks! That helped take the guesswork out of it. I found the correct db, and the backup is running properly now. :slight_smile:

1 Like

Great to hear and glad to help! :slight_smile:

What i’ve learned:

  • easiest way to correlate db to job is to rename db through gui
  • great feature would be to save encrypted job description to backup destination for adopting/reimporting (sorry @kenkendk,:slight_smile: but i think that still would be a great feature for hardening/securing/backing up the backup itself and preventing the user from harm if something stupid to the local things regarding duplicati configs happens
  • forums with engaged people (this one goes to @Pectojin!) are great.

What should happen if the user renames the backup?
Should we rename the file? What if the file is not named after the backup job before the rename?

What if they also use it from the commandline? Just ignore this and assume they know what they are doing?

Hmm… I’d say, ask if they want to rename the db as well.

For UI, maybe add a database name field under the job name field when a new job is being created. Autofill it as they type the job name, and have a way for them to override it if they want. Same for when it’s being edited. (I’ve seen this kind of workflow used when something needs a “machine name”. It works well.)

If someone is using it from the command line, I would assume they know how to reference the proper db file. I know every time I’ve used the command line, I’ve had to just look up which database file to point at.

I never have created a database from the command line, though. So I’m not sure what that workflow looks like.

I recently had a Docker issue that ate my backup config. Luckily it wasn’t very complicated so I was able to make a new job to point to the existing destination, but it did make me think it would have been nice to be able to restore the backup settings from the backup itself…