Shadow Copies to the rescue - DFS-R killed my data

Yesterday, I finally got round to plugging the new disks I bought back from Seattle into one of my servers which is destined to become a main file server at home. I have one share containing around 60GB of data and used the new DFS-N and DFS-R capability in Windows Server 2003 R2 to copy the data from the existing server to the new server. Simply a case of using DFS-N to add a second namespace server, and then use DFS-R to create an exact mirror, ACLs and all. Yes, takes a while to wait while 60GB of data is replicated, but come back a couple of hours later and it was all done. Therein probably also lies the "problem" (as in PEBCAK).

The next thing I did was to delete all the data from the share on the old server - don't need that anymore now it's migrated and shared from the new disks on the other server, do I? Well, yes, actually I do. Having DFS-R doing (by default) two-way replication between the servers means that any deleted data from one server is - yes, you guessed - also deleted from the other server. Also, the DFS Conflict/Deleted bucket threshold is nowhere near big enough to hold all 60GB of data. At this point, I was worried - very worried really. I have some older backups of this particular data, but it isn't "critical" - almost all of it was music ripped from my CDs and vinal, plus a few movies, painstakingly cataloged over a few years. Easy enough to restore if I had the energy and by not backing up it saves a huge amount of DVDs and time - it's on hardware RAID after all. (BTW - all critical data I do backup up!).

This morning, I was thinking about how to recover the data using one of those NTFS file recovery programs for example, but realised the trump card. I had enabled shadow copies enabled on the volume holding the data - albeit I had set the threshold to 50GB of data (default is 14GB iirc), so although I will have lost a small amount of data, it's better than nothing. Time to turn the threshold limit off, I think and dig out the old vinal....