Migrating from User to Service install on Windows

[JonMikelV]

Glad it worked for you!

And thanks for the tips - I’ve removed the duplicate step and tried to add some clarification to steps 2 and 3.

I have a feeling step 2 may get a little more complicated as I think there might be yet another potential location where the files could be, but I haven’t confirmed it yet (it might only be used in the latest canary).

[tophee]

Is it normal that duplicati still creates .sqlite and .backup files in C:\Users\Username\AppData\Roaming\Duplicati even when I switched to service? Cause that is what I’m seeing right now.

[JonMikelV]

I haven’t checked that yet but I suspect it might be “normal” if not “desired”.

If you look at “Advanced options” on the “Commandline…” page does your dbpath setting show the tray based or service based location?

[tophee]

does your dbpath setting show the tray based or service based location?

Well spotted! It’s still the old path there. I suppose changing that path should be step 3 of the tutorial?

[JonMikelV]

I suppose changing that path should be step 3 of the tutorial?

Erm, well - I tried that but in my testing it didn’t “take”. For what I was doing it didn’t cause me any issues so just ignored it.

Here’s what was said about it in a few other topics…

Changed dbpath not reflected in Commandline?

Since you mention “Commandline GUI under Advanced Options”, I should mention that the value in “Advanced Options” is ignored

Stuck on "Starting …"

Internally, the database path is stored in one place, and options in another. As many operations from the WebUI needs access to the database, it made sense to just hide the database things from the users.

I have been planning to fix this a bit by adding some logic that checks if the user has changed the --dbpath option and ask them how to handle it, but for now it is a bit obscure.

[tophee]

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

Changed dbpath not reflected in Commandline?

Since you mention “Commandline GUI under Advanced Options”, I should mention that the value in “Advanced Options” is ignored:

Which explains why

Erm, well - I tried that but in my testing it didn’t “take”.

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?

Found 240 remote files that are not recorded in local storage, please run repair

when I moved to duplicati as a service, it could no longer find the database file because it was still looking for it in the old location (under %appdata%). It’s as simple as that!

[JonMikelV]

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.

[sanderson]

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

[JonMikelV]

I personally would prefer Duplicati to use c:\ProgramData\Duplicati when running as a service

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.

[kees-z]

@JonMikelV

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.

@sanderson

I personally would prefer Duplicati to use c:\ProgramData\Duplicati when running as a service instead of …systemprofile\AppData

There’s a discussion about something similar here:

Duplicati creates large files in the roaming part of the user profile on Windows

[kenkendk]

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

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

[teknolai]

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?

Found 240 remote files that are not recorded in local storage, please run repair

when I moved to duplicati as a service, it could no longer find the database file because it was still looking for it in the old location (under %appdata%). It’s as simple as that!

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?

[JonMikelV]

Is there a way to migrate my backup-db to the “systemprofile”-folder

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.

[teknolai]

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?

Thanks!

[JonMikelV]

what steps are necessary to migrate the backup-sqlite files

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)

[teknolai]

Move (or copy) the existing database to the new location and point the service job to it
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.

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!

[JonMikelV]

maybe I could suggest an update in the migration guide, to move all the backup database-files with the “Move existing database” button

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

[mael2]

Move the following from the “Src:” folder to the “Dst:” folder as shown bellow

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.

[JonMikelV]

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.

[wetterkrank]

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…