Windows Backup – How to Use rdiff-backup and Ignore $recycle.bin and System Volume Information

I think their software works fine, except that you're "pushing" a feature beyond its intended limits and seeing an artifact of a protocol implementation. I'm don't think that running backups through the TS client drive redirection feature is going to work. I would say that the "subdirectory" behaviour you're seeing is because of artifacts of the TS client drive redirection feature (which is its own protocol and not "normal" SMB2/CIFS/SMB file and print sharing).

I'm running the following command on a W2K8 server computer daily with success, for example:

%SYSTEMROOT%\System32\WBADMIN.EXE start backup -backupTarget:\\adminserver\backups\FTPServer -allCritical -quiet

The path specified there is another server computer accessible over SMB/CIFS. Backup to a subdirectory that way is no problem.

Is the a compelling reason not to just give the VM access to another machine via SMB2/SMB/CIFS?

Edit:

You're misunderstand me when I say that you're "pushing" the feature. I'm not trying to "apologize" for them. The TS client drive mapping feature should act just like any other networked filesystem. It should be reliable enough to push potentially tens of gigabytes across in a backup scenario like you describe. It should work.

What I'm saying is: As far as I can tell, by looking at the "tone" of docs re: the TS client drive mapping feature it's intended to be used for casually moving data between the client the server. Further, it's a virtual channel protocol for RDP that's wholly and totally unrelated to SMB/CIFS, so it doesn't have the years of being "beaten on" that SMB/CIFS does.

I've heard reports of the feature being very unreliable when used as the location for saving documents from the Microsoft Office programs, for example. My take on this is that while this feature should work fine, it seems very likely that Microsoft isn't testing it for use as a general-purpose networked file system. As such, what you're doing is "pushing" the feature beyond its unstated design goals.

I'm right there with you re: UNC's making remote resources "just be a folder". The MUP driver should make any UNC act like "just a folder". After years of dealing with problems in older versions of the SMB redirector (remember "Oh, just disable oplocks", anyone?), the Novell Netware client, various NFS client implementations, and Microsoft's own WebDAV functionality I don't just trust any UNC-based network filesystem provider to work.

It's infuriating when I find a feature in any application or operating system that doesn't work "as advertised" (either from Microsoft or otherwise-- it just seems like Microsoft does it more often). What you're doing is the same thing that all of us in the industry do-- trying a feature out to see if it meets our real world requirements as well as the marketing gimmick requirements.

You're finding out that this feature doesn't meet your requirements. You have two choices-- complain to Microsoft or find a different way. To my mind, complaining to Microsoft is futile (unless you're a large enough Customer to attract attention with your complaints), so the alternative is to find another way.

That's why I said what I said. Not because I think you're doing anything wrong, because I'm apologizing for Microsoft's shoddy programming on this feature, or because I think it's right for the feature to be "sold" as being a true UNC-based networked filesystem drive when it's obviously "got issues". It is what it is, and you just have to deal with it or move on and find another way.

The process for dealing with deletions when you've run out of space is described in the unofficial FAQ under How do I remove files from the backup set. Repeating here just for completeness.

This method is very dangerous and shouldn't be used, unless the files that you want to remove are causing your backup drive to run out of space and your only alternative to removing those files is removing entire increments.

IMPORTANT: Properly speaking, you should do step 4 for every increment of mirror_metadata. Rdiff-backup prior to 1.1.1 does not mind having extra mirror_metadata entries for files that are removed from the backup set this way, except in the most recent version of mirror_metadata. However, at 1.1.1 the mirror_metadata handling changed -- rdiff-backup now diffs the metadata files -- and it's unknown whether having extra entries in these diff'd files will affect restore operations. (Technical note: the mirror_metadata diffs are NOT using the same method as file diffs. They are not rdiff delta files, but plain text files (and no, they are not ordinary text diffs either). Because of this, it is safe to hand-edit them, so if you need to you can do step 4 on these diffs.)

1. Check the time -- make sure it is not close to time for a scheduled run of rdiff-backup. Also make sure rdiff-backup is not running.

2. Go into your mirror target directory and delete the file or directory there.

3. Go into rdiff-backup-data/increments on the target and delete all traces of the file/directory there. Important! If you are removing a directory, make sure you find and remove all of the *.dir files for it as well! If it's a file, make sure you find and remove all of the *.missing files (if there are any). Be careful not to remove anything that isn't related to the thing you're trying to remove, or you might lose the ability to restore other files.

4. Important step! (and WARNING this is untested with rdiff-backup 1.1.1 or later) Go back up into rdiff-backup-data and gunzip the latest mirror-metadata file. Edit the mirror_metadata file in a well-behaved text editor (WARNING! Do not use pico or nano or anything else that might automatically do line wrapping!) and remove all references to the file or directory you deleted. Be very careful not to mess up the format of the file.