Migrating from User to Service install on Windows

Okay, I see. I guess this one is quite relevant:

Which explains why

But, in if the database path stays the same after moving to duplicati as a service, why are you telling people to move the database?

Good question - I put it in there because that’s where the database landed for me on a straight up service install, so rather than having a half-here-half-there setup I was hope to replicate what would have happened if they installed as a service from the start.

Secondarily, leaving the dbpath under a particular user’s account MIGHT end up running into permissions issues depending what credentials the service ends up running under.

But it is perfectly valid to leave the “Duplicati” folder where it is and add the appropriate parameter (I think there is one but I forget what it is) to the service startup so that it knows where to find the dbconfig.json and .sqlite files.

My first install I did a normal install and later converted it to a service (running as SYSTEM). I had to move the .sqlite database files manually from under my user profile AppData directory to C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati. Starting up without moving the config database acted like a clean install with zero knowledge of my existing settings or backup jobs.

Since then I’ve just been installing as a service initially without performing a normal install first.

I personally would prefer Duplicati to use c:\ProgramData\Duplicati when running as a service instead of …systemprofile\AppData. It seems a little cleaner in my mind and more in line with what I see most applications doing, but it doesn’t really matter. I could always move it if it really bugged me :slight_smile:

I haven’t tested this yet but I believe if you add --protable-mode to the service startup parameters it will indeed use the folder you mentioned.

--portable-mode stores all settings, backup configurations and local databases in a folder Data, located under the program folder.
If Duplicati is installed in C:\Program Files\Duplicati 2, --portable-mode will store everything in C:\Program Files\Duplicati 2\Data.

There’s a discussion about something similar here:

You can set the environment variable DUPLICATI_HOME=C:\ProgramData\Duplicati and it will stop using %LOCALAPPDATA%Duplicati.

1 Like

Thanks for a great migration guide. Unfortunately I’m stuck with the same error as @tophee is describing.

Is there a way to migrate my backup-db to the “systemprofile”-folder, so that I don’t have to start my backup over again?

Sure, but I’m not sure which error (“remote files” or “missing database”) you mean when you say you have the same error as tophee.

Sorry for not being more precise.

I get the “Found xx remote files that are not recorded, please run repair” error, because the backup-job database is not moved. So instead of reading the sqlite file per backup-job from “systemprofile”-folder, it continues to read from my local user folder instead. (And when I moved the sqlite-files, it recreates empty ones.)

So my question is what steps are necessary to migrate the backup-sqlite files? :slight_smile:

Thanks!

Got it!

You options at this point include:

  1. Run the repair which will rebuild the database based on what’s in those “xx remote files” (though this can take a while depending on your backup size)
  2. Point your service job to the existing database location (not recommended as it could be lead to confusion as to what’s stored where)
  3. Move (or copy) the existing database to the new location and point the service job to it
  4. Move (or copy) the existing database to the new location and rename it to match what the service job is already looking for

For 2-3 you’d want to use the job “Database …” menu. In there you can put the actual path to your database in the the “Local database path” field.

Most likely, the folder you want the database to live in will be:

  • C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati (unless you’re using the portable mode parameter)
1 Like

Thanks a bunch! The “Database…” menu was exactly what I was missing. It also allowed me to move the database.

So maybe I could suggest an update in the migration guide, to move all the backup database-files with the “Move existing database” button? It did at least do the trick for me.

Thank you for your help! :smile:

Good idea! I went ahead and made the first post a Wiki so feel free to update it based on your own recent experience! :smiley:

1 Like

For me this didn’t work. Duplicati re-created the DB in the original user folder and then threw some error that it cannot be renamed. Moving everything BUT the sqlite file seems to work.

1 Like

Sorry to hear our steps didn’t work for you, but I’m glad you figured it out.

Do you recall any specifics of what you did or what the error said when you couldn’t rename the database file? I’m wondering if the file was in use so the rename couldn’t happen.

Hey, one small note.
After the migration Duplicati can’t find %my_documents%, %desktop% etc. source folders (if they were included in the backup) because it’s looking for them under %userprofile% path which for the service points to \Windows\system32\config…

2 Likes

Are these instructions now outdated? I followed them to the letter, and have ended up with a huge mess now. FWIW, I’m a sys admin, and follow(/create) instructions like these on a daily basis. This is not challenging stuff.

The real problem is that duplicati apparently no longer recognizes my database. I’ve got about 300GB of files that I spent the last several days uploading to B2, and it looks like I’m going to have to start from scratch. It gives me the error about finding 11XXX files not recorded in local storage. I checked to make sure it’s pointing to the correct path (it is - I’m looking at the DB in that path). I tried to repair the DB per the error message’s instructions, but as soon as I click the “repair” button under the DB menu, it just takes me back to the home screen with no indication that a repair is being attempted.

My first thought is to wipe out duplicati and reinstall from scratch, but even if I export my settings, I’m kind of doubtful that will allow me to not have to start my backup all over. Any suggestions?

Some other notes about the questions that are likely to be asked (or steps that are confusing):

  1. I did close the tray icon, and all duplicati processes, before beginning. But the tray icon continues to come back. It’s not in the startup menu. Does it automatically start every time the service is started, or if you run Duplicati from the start menu? That should be mentioned.

  2. The steps listed here about moving the database seem to be very wrong, based on later comments. The portion about src and dst is missing a few words, which makes it very confusing. But it seems like the correct way to do this (if it’s even truly needed) would be using the “Move existing database” feature? The DB move seems to be the root of most of the rest of my problems.

  3. Port 8300 works, but port 8200 tries to go through the first run setup process. As I said, the tray icon was closed. Is 8300 vs 8200 a problem? No real details of the difference given here.

Not that I’m aware of.

The initial post should be a wiki so anybody can edit it, but as I recal when the src / dst comment was made I went and updated the post as suggested.

I suppose in theory you could use the built in “Move existing database” feature but you’d need to do something like:

  • shift to service so you know where the database files will be stored
  • run the tray-icon using the old setting (so NOT attached to the new service server)
  • use the “Move existing database” feature to move from the tray-icon based folder to the service based folder

But I think that still won’t bring over your jobs and other settings.

It’s not a problem, but it can definitely be confusing. When Duplicati starts it first tries to grab port 8200. If that’s not available, then it increments by 100 and tries again (so port 8300) and repeats as necessary until an open port is found (so next would port 8400, 8500, etc.).

Normally a service starts before any users have logged in so usually if you have Duplicati running as a service it will be at port 8200 (this can be fixed / specified with a parameter if needed) and uses the service based storage locations (such as stuff in C:\Windows…). When the user logs in and runs the tray-icon it starts it’s own backend server which grabs the next port (in this case 8300) and uses the user based storage locations (such as C:\users\[your user name]\Roaming\Duplicati…")

I agree - I’d suggest starting by doing a system search for *.sqlite files to see if we can find your “misssing” database and get it put into the correct location.

@JonMikelV Great guide, but putting it in C:\Windows is possibly dangerous as the Windows directory now gets recreated when you update Windows. I just updated to the Windows 10 April 2018 update and Duplicati could no longer find my backups! I guessed what the problem was and copied the files over from the C:\Windows.old directory manually and it seems to be fine

Yeah, we know about the larger Windows updates not recreating everything as it should.
Unfortunately, that’s the folder Windows uses by default for the localhost user.

I know of at least one suggestion for Duplicati to check Windows.old if it finds absolutely NO config stuff, but so far it’s been a relatively infrequently occurring issue so it’s not high on the priority list.

But as more users move to service based usage that may change, particularly if Microsoft keeps jacking up the Windows folder during updates.

May be better to put DB to ProgramData\Duplicati 2 folder? May be in subfolder named localsystem.

1 Like