1

I've noticed the following "bug" on a DFS volume with shadow copies:

Pretend you have the following folders/files under shadow copy versioning, going back two weeks.

MyDirectory
+ MyFile - Modified Date 8/1/2009

The current date: 8/30/2009

You have another version of MyFile stored elsewhere, with a modified date of 7/1/2009.

Copy your other version of MyFile into MyDirectory, overwriting the newest version. I expected that you could roll back to the version that was there when it last imaged, say on the prior day and recover your 8/1 version. Not the case. Now, when you go to look at previous versions for the past two weeks, the versioning of that file will be entirely lost, and you'll be stuck with your older 7/1 version. Suckage.

Questions:
(1) Is this intentional, and if so, what's the rationale? I assume that DFS picks up on the versioning based on the current file, and that's what's wiping out prior versions, but it seems like a fairly stupid/naive way of handling versioning to me.
(2) Is there a way to backtrack out of this, without resorting to restoration from other backup mediums?

Thanks!

patjbs
  • 258
  • 2
  • 6

1 Answers1

1

I think it's more intuitive when you visualize a timeline. Initially, assume you have save points like so:

8/1 .....8/10.... 8/30

If you want to revert back to the 2nd save point, make changes and edit, you now have:

8/1 .....8/10.... 9/1

8/30 has been deleted. The alternative would be:

8/1 .....8/10....... 9/1
... ... ... ... ... |...8\30 (maybe someone will help fix this lame formatting)

I could see the multiple timeline branches getting fairly space-intensive, and a pain to manage & navigate. So naturally, when we turn back the clock all the way back to 7/1, it will also wipe out the tree that's been "rewound".

The way I understand it, DFS is intended to be a fairly simplistic method to handle this. Anything more complex and I'd look into a content management system (from Sharepoint to Documentum, depending on how serious you want to get).

As far as tricky DFS restoring tips, sorry, I got nothin. I'd be pulling out the tapes. (assuming you've already checked the ConflictAndDeleted folder)

Kara Marfia
  • 7,892
  • 5
  • 32
  • 56
  • As I understand it, DFS doesn't branch like CVS does, though, on commits or changes like you are talking about here - I thought it simply took snapshots at particular timepoints. I wouldn't expect it to handle versioning/branching - but I did think I would be able to access those prior snapshots. I thought it was dumber than you mention, and simply functioned more of a spot differential archive system, in which case you wouldn't see this behaviour (the rewinding of the snapshots). – patjbs Sep 01 '09 at 16:47
  • mixing my terminology here - I don't mean DFS, but really the Shadow Copies – patjbs Sep 01 '09 at 16:52
  • Admittedly this is just my impression of the behavior from observation, rather than any dedicated research of docs, and I could definitely be missing something. – Kara Marfia Sep 01 '09 at 16:56
  • I just read the whitepaper on the shadow copies, and it states that it performs block-level copies of any changes that have occurred since the last shadow copy. So indeed, according to the whitepaper, the shadow copy system is supposed to function as a primitive differential backup system. I was unable to find any reason why the introduction of a file with a earlier modified date would cause the loss of shadow copy data however - if it was a differential system, you would simply expect those copies to still be present. – patjbs Sep 01 '09 at 17:00
  • Unless it sees it as a completely different file and simply overwrote the other file with all version information? We need the opposite of this post - http://blogs.technet.com/askds/archive/2008/12/17/understanding-file-date-time-behavior-in-dfsr-replication-and-better-ways-of-knowing-that-a-file-has-replicated.aspx – Kara Marfia Sep 01 '09 at 17:24