I’ve successfully enabled backups of several network shares using the Windows client, but I’m seeing extremely slow incremental backups as the client does full scans of files that have been backed up already.
For example, if I add a network share to be backed up by using the UNC path name (i.e., \server\share), the initial backup happens as expected. However, future incremental backups, which should do just a quick scan to see if any file has changed, do not perform like this. Instead, the UrBackup client is reading all files again, pulling their contents over the network, for every incremental backup.
It appears that UrBackup’s change detection mechanism doesn’t work over network shares. Does anyone know if that can be changed or improved?
The solution should be to do the backups on the machine that hosts the shares, so it is a local (or iscsi mounted) drive. Unfortunately I’m running into problems with this as well…
Yep, that’s exactly what I did in the end. It’s not a big problem for me, because the UrBackup client isn’t so resource-heavy. But it would be nice if it could be “smart” about handling Windows shares. Perhaps the problem is because VSS doesn’t work against Windows shares?
I don’t believe I had your issue in the linked thread. I did have to setup the client to run as the user that owns the shared files, but that wasn’t a big problem. I was mostly concerned about the terrible performance that requires all files to be sent over the network for every incremental backup. But then again, I never tested those backups, so I’m not sure if they were done properly.
The principle of VSS is to redirect writes to the filesystem into a temporary location in memory, to prevent the data on the disk from changing while the backup is happening.
But doing that to a network share would not guarantee the data does not change, as there can be more than one client. So the only solution is to run VSS on the server side, not necessarily the urbackup client that reads the data.
Thanks for the explanation – that makes perfect sense.
CrashPlan could handle backing up Windows shares. I don’t know exactly how it did this, but it would be a nice feature for UrBackup, which can’t seem to gracefully handle situations where Windows VSS is not available.
CrashPlan’s memory usage was HORRID when VSS failed… even Macrium Reflect isn’t memory friendly in that situation…
Though managing backup in the absence of VSS would be nice… I have a box or two with FAT(16/32) partitions, and UrBackup refuses to image them, since VSS isn’t supported…
In my particular case that wouldn’t matter… no WRITING takes place to those partitions, at least, not more frequently than monthly…
hmmm… maybe uroni could add a feature that allows normal incremental backups for read-only mounted drives? That principle would also transfer to linux with filesystems that don’t support snapshots
edit: I just realized I have no idea whether windows lets you mount a drive read-only.
You can use ATTRIBUTES VOLUME SET READONLY in DISKPART however sadly that only works with NTFS volumes, and applies to the entire disk if it’s MBR rather than GPT.
In the case of the FAT16 volume, I could probably remove it entirely… since Win10 supports mounting .iso files, that machine has been successively upgraded from XP to 10, which didn’t, and the FAT partition contains the content of a CD addressable by drive letter to allow a certain program to run without the hassle of inserting the CD… content of that partition will NEVER change.
[edit] A setting “Ignore VSS failure for this volume (only if you know no writes will take place!” setting would be nice [/edit]
[/edit]