Unattended Backup Log and Drive

Good Morning, I’ve implemented with the Windows 10 Scheduler an Automated Backup process.
I call the Scheduler by Trigger when plugging in the USB-Drive.
(Idea from Wolfram Gieseke!).
It works fine, but I’ve investigated two things:
The log will not write in the database, as the Scheduler called Duplicate2 CommandLine.exe.

If you create the Backup, the external USB-Drive will shown as fixed drive and if you forgot to connect and have already started the program, you have to close the program first, add the drive and the you will see it when you start Duplicati again.

Any Ideas to solve this ?

Hello @lkuhnert, welcome to the forum!

The “fix” for this depends on what you’re trying to accomplish.

It sounds like you want to be able to plug in a USB drive and have Duplicati kick off a backup - which you’ve accomplished with the scheduler trigger. I’m a little unclear on what you mean about the log not writing in the database - do you mean that if you run the web interface you don’t see the job execution history?


As far as starting the job BEFORE attaching the drive, I would expect the job to error out because the destination isn’t available. But if it’s not doing that, then you could consider using the --alternate-destination-marker=<file name> parameter which allows you to specify that a particular file must exist in the destination drive root OR the destination folder for the job to continue.

That way if the job starts but the drive isn’t attached then the file won’t be found and the job should quit.

Another option to consider is a --run-script-before-required script call in which you could check for a particular drive letter or file existence yourself. You could even have the script check file dates in the destination and not let the job run if it’s been less than X minutes / hours since the last destination file was changed.

This opens the door for scheduling with the web GUI on a frequent schedule (say every 10 minutes) that could look something like this:

  • start script every 10 min
  • if drive not found stop job
  • if drive found check dates in destination
  • if most recent date less than 4 hours ago stop job
  • if most recent date MORE than 4 hours ago allow job
  • backup runs

With a setup like that, a backup would run within 10 minutes of the USB drive being plugged in but ONLY if it’s been at least 4 hours since the last time a file was backed up.

Hello JohnMikeIV,

many thanks for the reply.
Your interpretation is correct, the backup log will be written in the database, but not shown in the web-interface, when you start it.

The Windows Scheduler Idea based on the trigger is from Wolfram Gieseke an author of Windows and other books.
Attached the XPath script:


*
[UserData[UMDFHostAddDeviceEnd[InstanceId=‘ID’]]]



You have to find the ID of the drive in the Windows protocols.

Your Idea with the script sounds much better, as with the trigger, you cannot stop the job only to check the drive.
More important would be the problem to attached the drive when you already started Duplicati.
Let my try your solution and I’ll report here.

Sorry me again,

as I’m not really familiar with the Forum syntax, the script is not complete.
Please ignore it.
The Xpath query script will check the drive ID and the start the job, with calls Duplicati CommadLine with the exported parameter.

Good luck!

When posting something like that you’d probably want to put “~~~” before and after it.

Then it will show up like this which allows for really long lines that can be scrolled instead of wrapping which makes stuff like scripts hard to read.  :-)

Hopefully that makes sense...

I don’t have the specifics with me, but variations of the following commands might help determining drive letter with a batch file:
wmic diskdrive get name,size,model,SerialNumber
Get-CimInstance Win32_DiskDrive | Select-Object Model,SerialNumber (PowerShell)
Get-PhysicalDisk | Select-Object FriendlyName,SerialNumber (PowerShell)

Hi JohnMikeIV,

great thanks for this support, as I’m looking for new commands of the PowerShell, which is not so simple.