Hi all,
can’t find how i can run DuplicatiVerify.ps1 in “utility-scripts” folder.
Anyone can help me?
Many thanks
Paolo
What exactly are you trying to do?
I have not run this script myself, but the python version has a bit of a description as to its purpose:
If Duplicati is producing a backup with the option --upload-verification-file,
it will produce a *-verification.json file on the backend, which can be verified
by this script. Simply run this script with the path to the backup
folder as input, and it will verify all *-verification.json files in the folder.
1 Like
Hi and thanks for reply.
I’ve a issue with duplicati. I get “hash mismatch” error after a backup and i can’t solve (tried with repair, verify with no goods).
I read about run this script to verify which files has this mistake so to delete them and retry to backup.
I don’t know how can i run.
If you weren’t using the --upload-verification-file option, then these scripts will not work. Plus, I’m guessing they would just confirm what Duplicati is telling you: that there’s a hash mismatch on one of your files.
What back end are you using (where are you storing your backup files)? One possibility is the file was not saved properly, and another is that the file was corrupted some time after being saved.
1 Like
I’m using Onedrive for business to store files. Probably (or for sure) there’s a file with this mistake. But i don’t know which one, and i don’t know how i can know that. Reading on forum i found something about DuplicatiVerify.ps1 to find the file, but i don’t understand how i can run it.
Alternatively, there’s another way to solve “Hash Mismatch”?
Many thanks
You should be able to see the name of the problematic file in the has mismatch error message. What does it show you? Depending on what type of file it is (dindex, dlist, or dblock) there may be different ways to solve the issue.
1 Like
Hi drwtsn32 and thank you very much for your interest.
Here the message i receive when lunch backup.
"
Mancata corrispondenza hash nel file “C:\Users\zwadmin\AppData\Local\Temp\dup-b9ee2213-b7d8-4278-9f9d-c75a8dcd0b6a”, hash registrato: KnPxWmTqxeLUImhL3ECpjxAqv4XfOCCzc4iIkBF+WCk=, hash effettivo YKs7YvixYYhipFjWigSmMQmOcBMWF7rCZU80prEEZCs=
"
I Can’t see any guilty files, so i don’t know who give me the error.
Thanks
Ok I wonder if this is in the testing phase. Can you confirm? Click on your backup job in the web UI, then click Show Logs. Do they show up with a Warning? Click on it to expand, do you see a Warning in Test Phase?
News Today!
Today (after 4 tentative failed to backup), all goes well.
It did a correct backup without problems (non hash mismatch error).
do i ignore hash mismatch error and hope in future backup goes well?
However i’ve read this in forum:
"I run DuplicatiVerify.ps1 from C:\Program Files\Duplicati 2\utility-scripts
And after couple minutes I saw:
**** Hash check failed for file: duplicati-20180221T192419Z.dlist.zip.aes*
So I renamed that file. Run backup. Duplicati told me to run repair so I did. And after that error message was gone."
The problem is: how can i run cripts file?
The PowerShell (.ps1) script needs local file access. I’m not sure you have that, but you can tell us.
If you don’t have files, you can use Duplicati’s usual messages, or use test from GUI Commandline.
PowerShell scripts can be trouble to start, but if they’re refused, they’ll at least tell you how to fix that.
Below is from a PowerShell window, available from Start menu (type to search) or maybe right-click.
Your system might have right-click start configured to Command Prompt, but it can start powershell.
PS C:\Program Files\Duplicati 2\utility-scripts> .\DuplicatiVerify.ps1
.\DuplicatiVerify.ps1 : File C:\Program Files\Duplicati 2\utility-scripts\DuplicatiVerify.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170
How do I manually run a ps1 file? has an alternative to doing a longer-term change to execution policy.
Its formatter might have swallowed a backslash. That was probably trying to say .\somescript.ps1
You see this a lot on command lines where you need to explicitly give the directory. Dot is current one.
You can alternatively use a full path starting from drive letter, or use cd command to change directory.
If you’re able to access your destination files directly, e.g. from a Command Prompt, then you can run PowerShell script (most likely) to do so as well, and files will be streamed to your system on demand.
You do have to set up the upload-verification-file beforehand, so the script will know what it should see.
If you’re not able to access files, then you can let Duplicati read the files via its test as described at top.
thanks ts678
i’ll try with Duplicati test.
By the way: error “hash mismatch” appears again. 
The elephant in the room should be that the temp folder is being backed up.
What folders are you trying to backup? Duplicati will work fine if you want to backup your Desktop or Documents folders but it won’t do a whole user profile.
As for running a .ps1 file, the message that @ts678 posted to goto https:/go.microsoft.com/fwlink/?LinkID=135170 is correct but that article isn’t great so you may not be much further ahead. You need to make changes to the local script execution policy or .ps1 files won’t run. By default the ExecutionPolicy is Undefined (disabled) and scripts will not run.
Just so you know, there are potential security issues with enabling scripting on your computer, the powershell is very powerful and can do anything you can, so one bad/malicious script can really muck things up. So long as you trust the script source you should be fine but it opens a door that would otherwise be closed firmly.
With that said if you still want to enable powershell scripts open a powershell prompt, Start> Windows PowerShell> Windows PowerShell. At the flashing cursor type, Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser then press Enter, it will then ask if you are certain and if so type Y and press Enter. At this point you can close the powershell window via the X or type exit and press Enter. While you can test scripts in the powershll prompt, the powershell ISE is better suited for the task, it can be found in the same folder off the Start menu only it’s called Windows PowerShell ISE.
If you want to undo the ExecutionPolicy change and set it back to Undefined run the following command. Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser Note: In either case we are only changing the ExecutionPolicy for the current user vs being system wide.
All that powershell stuff aside it does sound like changing your source selections to not include unneeded folders may resolve things.
Where is that shown? The message about hash issue on Temp file is because downloads go to Temp.
I just quoted Microsoft’s message. There are some more links from me below that on execution policy.
The first one might reduce security worry by only being effective for a single run of a PowerShell script.
Example:
powershell -executionpolicy bypass -file ./DuplicatiVerify.ps1
cmdlet DuplicatiVerify.ps1 at command pipeline position 1
Supply values for the following parameters:
FileOrDir:
Ok, I see how I’ve misread the error, sorry about the confusion.
I know you’re not a dev but the value of that error to anyone other than a dev (and even then), seems quite minimal. So if the hashes for the Duplicati temp files are failing during the backup wouldn’t that almost have to point to a memory failure, be it RAM or the storage location for the %TEMP% folder? What else could be altering the temp files?
For a typical user that MS article isn’t all that concise not much you can do about that, MS articles have been getting worse and worse over the past few years. Having setup a powershell script on a new computer this morning the command was still fresh in the brain so I figured I’d save anyone else from having to figure out just what commands to run.
It’s not a direct alteration of a temp file, but means a downloaded remote file didn’t hash as expected.
There’s a hash stored in the database before upload, so a downloaded copy should give same hash.
Reasons for surprise errors include issues at the destination, transmission errors, or local problems.
Generally more context is needed, especially the remote file’s name so that it can be looked at some.
This might require having to ask for a live log (easier than a log file), or a stack trace. Example log file:
2021-12-21 13:03:15 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.BackendManager-RemoteOperationGet]: Starting - RemoteOperationGet
2021-12-21 13:03:15 -05 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Started: duplicati-bff94c78007a1440a9cfc1183b3ff4fbc.dblock.zip (678 bytes)
2021-12-21 13:03:15 -05 - [Profiling-Duplicati.Library.Main.BackendManager-DownloadSpeed]: Downloaded 678 bytes in 00:00:00, -8,388,608.00 TB/s
2021-12-21 13:03:15 -05 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-bff94c78007a1440a9cfc1183b3ff4fbc.dblock.zip (678 bytes)
2021-12-21 13:03:15 -05 - [Profiling-Timer.Finished-Duplicati.Library.Main.BackendManager-RemoteOperationGet]: RemoteOperationGet took 0:00:00:00.000
2021-12-21 13:03:15 -05 - [Retry-Duplicati.Library.Main.BackendManager-RetryGet]: Operation Get with file duplicati-bff94c78007a1440a9cfc1183b3ff4fbc.dblock.zip attempt 5 of 5 failed with message: Hash mismatch on file "C:\Users\Maintenance\AppData\Local\Temp\dup-7ded91bb-20ad-4819-b2fc-05fea4efc755", recorded hash: fYmvhRs17qW3mFlzEe3s7Wq9usrBcYgIi8FLIo+Mp4w=, actual hash T2IU5xNxovx9Jq4/MlTsCBKsTBAsHdAntqXJNyMiiGY=
Duplicati.Library.Main.BackendManager+HashMismatchException: Hash mismatch on file "C:\Users\Maintenance\AppData\Local\Temp\dup-7ded91bb-20ad-4819-b2fc-05fea4efc755", recorded hash: fYmvhRs17qW3mFlzEe3s7Wq9usrBcYgIi8FLIo+Mp4w=, actual hash T2IU5xNxovx9Jq4/MlTsCBKsTBAsHdAntqXJNyMiiGY=
at Duplicati.Library.Main.BackendManager.DoGet(FileEntryItem item)
at Duplicati.Library.Main.BackendManager.ThreadRun()
2021-12-21 13:03:15 -05 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Failed: duplicati-bff94c78007a1440a9cfc1183b3ff4fbc.dblock.zip (678 bytes)
2021-12-21 13:03:15 -05 - [Error-Duplicati.Library.Main.Operation.TestHandler-FailedToProcessFile]: Failed to process file duplicati-bff94c78007a1440a9cfc1183b3ff4fbc.dblock.zip
Duplicati.Library.Main.BackendManager+HashMismatchException: Hash mismatch on file "C:\Users\Maintenance\AppData\Local\Temp\dup-7ded91bb-20ad-4819-b2fc-05fea4efc755", recorded hash: fYmvhRs17qW3mFlzEe3s7Wq9usrBcYgIi8FLIo+Mp4w=, actual hash T2IU5xNxovx9Jq4/MlTsCBKsTBAsHdAntqXJNyMiiGY=
at Duplicati.Library.Main.BackendManager.GetForTesting(String remotename, Int64 size, String hash)
at Duplicati.Library.Main.Operation.TestHandler.DoRun(Int64 samples, LocalTestDatabase db, BackendManager backend)
To rig the above, I altered the first byte of a file then used the Verify files button. In this case, the red popup message named the file, but didn’t say what low-level problem was. Regular job log also did that, summarizing the issue as its first line (which I guess is better than nothing), then losing later-line details.
What one may like is just the right amount of high-level information and low-level detail. Don’t have it yet.