I recently wiped my windows machine and was using Duplicati to restore all my backups from my secondary drive. In the past, i tested my backups to ensure it backed up everything I needed, but when restoring to my newly wiped machine, my %localappdata% folder was missing. I only have roaming and locallow.
I restored what I can and put the old Duplicati files in a different folder just incase I can somehow restore it in the future.
I loaded my last backup config file and tried backing up my newly wiped machine, and the localappdata folder backed up just fine. So my config was correct and everything should have been working.
I am pretty upset right now as I lost a lot of important files and made sure everything in Duplicati was configured correctly. If my old config works fine on my newly wiped machine, that means that the config was setup correctly before the wipe as well.
You can look inside dlist files to see what that version had. See How the backup process works.
If encrypted, you can use AES Crypt (GUI) or Duplicati’s SharpAESCrypt.exe (CLI) to decrypt it.
Missing from what? The restore tree? The result of the restore? Any warning or error messages?
What sort of files? Backup destination (dlist, dindex, dblock), databases (which ones), job export?
If you have prior database, looking in a copy with DB Browser for SQLite would be an alternative.
Filtering PathPrefix table Prefix for the local appdata path would suggest if there are any files.
I have trouble parsing this sentence. I don’t know of any such variable in Duplicati. There is %APPDATA% that is used in exclude when selecting the Application Data directory.
Is your new installation using the same operating system version that the old one ? If yes, the paths should be identical and there is no reason I can see for restore to not have worked. If no, all bets are off and restore could very well not find the appropriate paths on the new setup - file paths are stored in absolute form internally, no such thing as %envvar% stuff.
If it is the case, setting a backup config on your saved data files could help you recover. You can do it in parallel with your running job, just take care of invalidating the backup job schedule of course. Then you could browse your old backup data and restore what you want.
wasn’t able to understand how to do this with the documentation you provided, but i am able to view my old backup by using the Restore > Direct restore from backup files method and my C:\Users\USERNAME\Appdata\local is not there. Only locallow & roaming are.
the folder was missing from my restore tree and result of the restore. no warning messages related to that folder path
my Duplicati backup destination files (dlist & dblock). not sure if i have a prior database or not. this is the only folder I have of my backed up files
by using the Restore > Direct restore from backup files method
%localappdata% is a windows environment label that simply refers to Appdata/local. that is all i meant
yes i just reinstalled windows 11. same version I had before
I can already browse through my old backup using the Restore > Direct restore from backup files method any my appdata\local folder isn’t there. only locallow and roaming. so not sure this will do anything. please let me know if i misunderstood you
Assuming you installed Duplicati the same way this time, the Database screen shows the location.
The job database name (not folder) is random and new with the import, but the folder is the same.
For non-service install, it’s usually in %localappdata%\Duplicati. Easiest migration is to preserve it.
If it got wiped with Windows, then the only source of history is the dlist files. Have any old ones?
Direct restore probably looked at the latest. Any chance that the configuration changed over time?
Looking over old dlist files is the lowest level way to see if your folder is in the filelist.json file.
If you don’t encrypt, then you can just unzip, and probably notepad will let you search file (crudely).
Do you have lots of versions? There are other ways to do this, but all of them are kind of awkward.
For example you could make a dummy job (don’t backup or do dangerous things) to recreate a DB.
You can then either look at it in a DB browser, or set all-versions and run find in GUI Commandline.
EDIT:
How did you do that, and when most recently? Maybe there’s an old backup version that looks better.
another possibility is that you could have installed Duplicati as a service in your first install. In this case, appdata is pointing at a system directory and there is not much useful to backup there. Still, you should find files in your backup under C:\Windows\system32\config\systemprofile\AppData\Roaming or something like that. If you exported your backup as a Json file, you’d find easily if it was a system install, the database would be also recorded under c:\windows.
I think it’s necessary to give more precisions on what you clicked on actually.
Here is a screenshot of a Win11 test install
what is under ‘Application data’ is the same thing as what is under Appdata\Roaming, actually.
BTW what I see under Appdata\Local is useless (crash data, temp files, cache…). Windows is not supposed to put important data here, the user data is normally stored under Roaming.
I don’t know history of this result. You said you got some old files from Direct restore, then:
Having old backups visible would not be the case if you started a clean backup after wiping.
Do you have some older log files too? That would mean that you moved your old database.
Would the 3:14 AM one today be the new backup, or is this the dummy DB repair I advised?
Logs are not on the destination, so if it’s pretty empty there, I guess image is of a DB repair?
Is that cd to AppData then dir local versus dir roaming? So you have Roaming\Temp? Seems wrong.
On a very clean Windows 11 VM (as well as on my regular system), the contents are highly different.
Some apps have both Local and Roaming data, but completely identical trees sounds highly strange.
How? Windows has several reset options of varying intensity but less than a full wipe-out-everything.
I forget what options you get if you boot from a DVD or USB. One is probably a very thorough wipe… Sometimes, when the goal is to fix Windows, I think there’s an in-place upgrade that wipes out little.
I’m still trying to figure out the story behind your screenshot, and how it’s able to show old backups…
If we can’t reconstruct the history, maybe it’s time to check dlist files. Are timestamps similar to dates encoded in the path (which are UTC)? Earlier I was trying to get you to open up the .zip to look at the filelist.json file inside. It’s a long line. If Local isn’t there, it’s not in that version of the backup any more. Checking dates is to make sure it’s the original content, and not something modified, e.g. by a purge.
This should build a partial temporary database, and if you go through the versions one at a time (ouch) without seeing Local, then it’s probably not in the dlist file (could check anyway), so not in the backup, which begs the question of how that was, and how you were testing that it was there at some past time.
What’s the time stamp on prior exported config, or do you know that it was just before the system wipe?
There are a lot of conflicting clues here, so this may take some work to try to identify all of the history…
If Source screen, here is why Application Data is AppData\Roaming, courtesy of Windows + C# design.
Possibly Restore screen got a similar effect. I don’t have one set up. Regardless, Local is not Roaming.
Questions are piling up here. The Internet claims that the AppData folders can be moved. Were they?
Possibly on Restore screen you can use the search box for some missing file to see if it’s elsewhere.
One that Windows 11 probably created is SharedCacheContainers, in AppData\Local\MicrosoftEdge.
You can also search for SharedCacheContainers in filelist.json. It seems to be a rather unique name, therefore you probably won’t get irrelevant search hits. What was the backup configuration anyway?
It looks like if you select Application Data in Source, config export shows its value as %APPDATA%, meaning if user that imports is different, the config will be for their user. I don’t know if that’s so here.
I think this is probably the same question as was asked earlier about the Source configuration clicks.
We don’t know what was backed up, how it was tested, or story of the database move/recreate, etc.
EDIT 1:
To illustrate looking inside an unencrypted dindex .zip file, here’s a sample view from File Explorer:
If the config export is encrypted, it can be decrypted with the mentioned tools, redacted, and posted.
There are other ways to drop things, e.g. by filtering. We hear it works now though, but how old is it?
What is “useless” data to you might not be useless to other people.
Historically “.\roaming” dir was supposed to be uploaded to the NT/AD Domain Controller if it used roaming user profiles. And while “.\local” dir was not included as part of the roaming domain profile, it still contained user data.
So Windows can and does put important data there and so do other apps too, and if you want to have a complete backup of your data, that folder is absolutely essential to backup!
