Duplicacy Backup Failure

Support
#1

I had problems with Duplicacy failing when backing up to BackBlaze and it was suggested that I try backing up to a local disk instead.

I have just tried this and it still fails, I believe due not being able to access open files.

Any ideas?

Best Practices: Which folders/directories to exclude?
#2

For better understanding:

  • Which version are you using (CLI, old GUI, new Web-GUI)?
  • Which operating system?
  • What is the full command you are using?
  • What kind of files are you backing up?
  • Can you provide a log?

When the problem is related to only a specific locked file, you see a message like this:

WARN BACKUP_SKIPPED 1 file was not included due to access errors

But backup of the others is accomplished.

#3

Sorry.

Web Gui
Windows 10
Not sure of the command as it is via the Gui, trying to backup the c: drive to a USB attached drive.
All files on C: is operating system, programs etc
duplicacy log.txt (656.1 KB)

#4

In fact, you are trying to back up multiple system files and program files (browser cache, etc.), which are blocked.

Generally, backing up Windows files in this way does not work well, because even if you can back up the entire disk, in a future restore of these files on a future drive (if you have a problem with your computer’s current drive), probably Windows would not work correctly.

The same applies to backing up software folders.

The two sets of files above (the operating system and the programs / applications) are usually installed on a new drive, and not restored from backup. If necessary, the backup of the respective installers should be done.

The really important folders, where probably your files are:
C:\Users\Jenny\Documents
C:\Users\Jenny\Pictures
C:\Users\Jenny\Music
C:\Users\Jenny\ ... etc ...

There may be other folders with important files for you too, outside this C:\Users\Jenny\ folder, and these other folders should also be included in the backup.

#5

So duplicacy cannot do a backup in the conventional sense ie one that would restore to as is?

Tape systems I used to use did full live backups is that not possible with duplicacy?

#6

As far as I know, Duplicacy cannot backup files that the OS and file system do not give it access to read. I would expect this to also be true for the machinekeys special folder.

If you were running Duplicacy on a VM host there might be some hypervisors that support VSS, which would let you backup live VM images.

1 Like
#7

The vast majority (if not all; I’ve never come across any…) of file-based backup software will never be able to restore a fully working bootable Windows Operating System. That’s why they generally recommend to omit system and program files - stuff that is easily re-installable anyway…

For a full system backup, you want a disk-based imaging software (such as the free Veeam Agent for Windows). BUT don’t let that stop you from using a file-based backup program like Duplicacy on top. You should always have more than one type of backup, and the file-level backups are more flexible, more efficient, can be run more often etc…

Having said that, you can get Duplicacy to capture in-use system files by using the -vss flag.

Although I’d still suggest not to include the whole of the C:\, but instead anything that includes user data - i.e. C:\Users and other data partitions.

4 Likes
#8

To a add to this – the hybrid approach works well:

  1. make infrequent volume level clones with system imaging software (acronis, macrium, veam, CCC, whathaveyou)-- ether monthly or after significant system changes, to local storage only. Goal - quick system restore after hardware failure/theft/natural disaster.
  2. Make frequent backup of user data only, separately – with duplicacy, both to local storage and offsite.

This accomplishes two goals:

  1. Irreplaceable user data does not compete with replaceable system and application files for backup space and bandwidth, which means your important data is protected sooner
  2. you don’t pay for storage to host system and transient files that are esily recoverable from e.g. download.microsoft.com

Restore flow in the event of total loss would be: 1. restore system backup and then 2. restore user data on top.

Having said that, you can get Duplicacy to capture in-use system files by using the -vss flag.

This still will not work – modern operating systems use quite a bit of trickery – such as reprise points, readonly filesystems and overlays – which Duplicacy cannot/does not/should not handle, so there is 0 chance that by copying files back you will end up with bootable system. And when secure boot and other wonderful things come into picture – just forget it.

3 Likes
#9

Indeed.

I only mention it since, for example, the C:\Users directory where user profiles are kept, contain a lot of in-use ‘system’ related files (such as ntuser.dat, which I believe contains the user’s registry settings, which further may include ‘user data’ such as usernames and passwords/keys etc.).

This can only be backed up with -vss, so I always suggest backing up such directories with that option.

Usually it’s good practice to completely isolate user data from system files, but that’s not always possible if one wants to run legacy apps and that data happens to be scattered across the OS drive - in Program Files etc… I personally think setting up symlinks is messy and would rather backup potentially unimportant areas, such as C:\ProgramData (-vss also suggest there), than find out later that I really needed a log or settings file stored in there.

1 Like