Upload external drives to the cloud

I’ve been using Duplicati for a while to backup computers to an S3-compatible cloud account. My tasks are typically 20-200GB and run on a weekly schedule. The systems are all over the place and as I do not have regular access I set up a central dashboard at https://www.duplicati-monitoring.com.

Now I want to take care of a number of external drives with 500GB each. I’ll assign a persistent drive letter in Windows, and of course, the initial upload will have to be monitored. What should I do after that? Seems the best approach would be to create a separate task for each drive, and send out a periodic reminder to users to connect the drive and click “Run now” in the Web interface. I’ll add tracking to the dashboard to be sure users do not lag behind. Sounds reasonable to you guys?

Hi @saul and welcome to the forum!

For a high-tech option, searching in the forum with Google found Device mount detection (USB or otherwise) however what wasn’t discussed there is how to tell the operator when they can unplug the drive. Having them use the web UI to start it could be combined with having them watch the web UI or the tray icon for the finish…

There doesn’t seem to be anything as nice as Windows Drive Letters for the source side, but if you plan to do backup starting at the drive root, you could maybe also insist on some marker folder being present (or it fails).

Making sure an unplugged drive is not seen as an empty drive would be important. I haven’t tried any of this…

Hi @ts678, happy to be here!

I played with Mount Detection in SyncBackSE (another favorite) but I understand it is not native to Duplicati so I won’t try it for now. Besides, I feel these tasks need to be manual because there’s only so much you can automate for users, and triggering a job that takes 10 mins at a minimum (between indexing and WAN comm) whenever the drive is plugged can interfere with Safe Removal and create a trail of “incomplete task” errors. I’d rather the user run it twice a year and let it run all the way.

Drive Letters seem to stick once you leave the territory of E, H, J and go for obscure letters that do not get in the way of new devices. The key is to use Disk Management in the first time. The letter will get reassigned when Windows sees the same drive again. I feel confident taking the letter route, but thanks for the tip on --alternate-destination-marker, it might come in handy.

I checked what happens when a profile is run with the drive unplugged. It is quickly aborted, so no risk there.

There’s also an option to tell Duplicati to look in multiple paths (drives) for the destination marker.

Also potentially helpful for your needs, version 2.0.3.10 added support for additional --run-script-before exit codes which should allow you to schedule frequent runs that will silently end (no error/warning) if the destination drive is not found.

Does that work for source drives? It seemed not when I spoke before on this, but I hadn’t actually tested it.

So yeah here’s a batch script to probe if the source drive is plugged.

@ECHO OFF
SET OPERATIONNAME=%DUPLICATI__OPERATIONNAME%
SET LOCALPATH=%DUPLICATI__LOCALPATH%
FOR /F "tokens=1 delims=;" %%S IN ("%LOCALPATH%") DO SET FIRSTPATH=%%S
IF NOT "%OPERATIONNAME%"=="Backup" EXIT /B 0
IF NOT EXIST "%FIRSTPATH%" EXIT /B 1
EXIT /B 0

No, only destinations. Sorry if I misunderstood the use case!

If it’s the source drive that might have a letter change then the your batch file looks like the right approach, thanks for sharing it!

However… It should be noted that Duplicati identifies files by their path, so if the source drive letter changes between runs then Duplicati will consider the new paths to be new files.

They’ll be backed up just fine, and very little extra data will need to be re-uploaded thanks to deduplication, however history won’t make sense (old drive letter files will look like they were deleted while new drive letter ones will look brand new).

Aside from this potentially causing odd retention cleanup (if you set keep 1 version but have 5 different drive letters over 5 runs, they’ll each be treated as 1 version) selecting versions for resting can get messy.

It would probably work way better to have the pre run script identify the source drive letter then map that as a shortcut inside a fixed-drive-letter folder being backed up (assuming Duplicati is set to follow shortcuts).

How would you configure a backup to deal with varying source drive letters (thereby allowing such confusion)? The tree-style picker seems to have to start at a letter (I suppose you could append later after setting another), and the type-your-path seems to allow no-letter, but I suspect it implicitly heads to Duplicati’s run-drive, likely C:.

In theory (I haven’t actually done this myself) I would make a folder in the c: drive specifically for this backup use (say, something like “C:\DuplicatiBackups”).

Then set up a job with that folder as the source and a shortcut policy of “follow”.

use a --run-script-before-required process to:

  • identify drive letter
  • if not found, abort (no backup)
  • if find, delete any shortcut in the c: folder
  • create a new shortcut to the found drive letter
  • run backup
  • profit! :slight_smile:
1 Like