Volume Shadow Copy (VSS) cannot be used on Drobo!

With the 5TB limit, that’s fine. But not with VSS in general.
VSS does work. And if it’s not working with Drobo, you can’t send your customers to Microsoft.
It’s you creating a device that pretends to be a harddisk but doesn’t behave like one. That’s your business, not Microsofts.

But again, your case has been the only case opened where you are having issues with VSS and the drobo. I can have my engineers test VSS again with a drobo.

Yes, please do that. And please reproduce what I did. Note your free/used space (in Dashboard!), create a big file, create a snapshot, delete the file (delete! don’t move it to the recycle bin!) and check your free/used space again.
If you gain free space after deleting the file, there is obviously something wrong!

So deleting the file should NOT give you more free space? I’m confused.

I knew you would say that…

The deleted file still exists in the shadow copy snapshot. If Drobo is aware of that fact, it has to see that space as “used” in order to be able to protect that data! The fact that deleting files gains free space tells me that Drobo is NOT capable of dealing with VSS.

I’m performing a 2nd test at the moment.

  • created a 2GB file with random data
  • calculated its MD5
  • created a VSS snapshot
  • deleted the file
  • creating another 40GB random file now

after that, I’ll

  • restore the 2GB file
  • calculate and compare its MD5

So you store the snapshots on the Drobo but the actual data is on your computer?

Sorry if these questions seem dumb, but I have never used VSS and trying to duplicate your issue.

No, Snapshots and Data are on the Drobo, that’s the usual way when you use VSS.
I think it would be useful if you’ll read http://en.wikipedia.org/wiki/Volume_Shadow_Copy_Service because I’d suck explaining VSS with my lousy school english :wink:

VSS does not create copies of the files. Creating a Snapshot marks the files as read-only and tells the OS to save further changes at other blocks of the disk.
Therefore creating the first snapshot of a 100GB used Volume only takes about 300MB additional space. But after that, you can delete your entire volume and restore its content from the snapshot later. The data is still available.
And this is why deleting (any!) files after creating a snapshot should NOT give me additional free space.[hr]
My 2nd test just finished. And as expected, the MD5 of the restored 2GB file is different from its original MD5.

Once again I’d like to shout out: Don’t ever use VSS on Drobo or your data will get corrupted!

Ok, one of my tier 3 engineers has been following this thread. He tested on Vista and his Drobo. He did EXACTLY what you did per your post and no free space occurred. It worked with no problems.

FYI: The restored file only contains Null-Bytes!

VSS is using raw Block-Level access to the drive which Drobo is not capable of BY DESIGN. I told you that one year ago and I tell you now!

VSS is used in lots of businesses to restore previous file versions in a very easy way. Doing this on Drobo actually erases the file. If I had a business, I’d charge DRI for not warning me![hr]
@Jennifer, can he please comment on that and repeat what he actually did step by step? And what about the 2nd test?

So when you restore, are the files not viable?

As I said, the restored file was filled with Null-Bytes… I don’t know other ways to explain that. I can send you the restored 2GB file if you want. Here it is: http://rapidshare.com/files/401782010/DroboRestoredFromVSS.zip.html (ZIP compression FTW!)

From my engineer on what he did:

He copied files to his DroboElite volume. Did a snapshot with VSS. Then held the shift key while deleting the files. After deleting the volume the used space was a little different. Then he right clicked on the volume in windows explorer and chose “restore previous versions”. After doing a restore previous versions the files are back and usable.

Is this different than what you did?

The difference is that I created another 40GB file between deleting and restoring the file.
Drobo maintains its virtual2real block mapping after deleting files (at least I hope so, otherwise DiscWarrior or other data rescue software won’t work at all) until the blocks are used for other files.

By just deleting and restoring the file, you didn’t change Drobos internal block mapping. By creating 40GB additional data in between, I did (at least with a high probability).

FYI I just did the same test again, but I used a 100MB and a 2GB file instead. This time the restored file was ok.
I’m fine with this result because I think the 2GB data just haven’t touched the blocks of the deleted 100MB file.
I’ll do the same again with 1GB/20GB and 2GB/40GB if needed and capture it for you.

If you try to reproduce this, please also use big files that use lots of blocks. Small files just get stored in different blocks and you won’t be able to reproduce this.

FYI: http://www.youtube.com/watch?v=DjHEX7IuKXM
This Video is public now, read its description.

I’m still working on tests here (I was finishing off my own test suite, now working on your steps)… I’m working with 20+GB files, so that should hopefully be enough to significantly rearrange the blocks.

RFZ: Can you try a test using an encrypted Zip file, and not TrueCrypt?

The reason I ask is this section from the TrueCrypt manual, Known Issues & Limitations section:

I’m not familiar with TrueCrypt, so I’m not entirely certain this does or does not apply to what you’re doing, but I am using encrypted zips with different passwords to illustrate file rewrites. This gives me both the ability to error-check the file and in the event that somehow the wrong version is restored, be able to verify which version it is by validating the password.

I use “md5sum” to check file integrity. TrueCrypt is only used to create big files with random data with a specific size. I do not mount those TrueCrypt Volumes, they are just files with no specific function at all. I would use a “Write X megabytes of junk to a file” application instead of TrueCrypt but I don’t know any. The limitation you mentioned only applies to mounted TrueCrypt Volumes.

So you are using encrypted ZIP files an their own CRC-Value to check file integrity? But how do you create big files? By adding random files into the ZIP?
Validating by password only guarantees that the file was intact if you extract its complete contents afterwards. Just opening the file only checks the first few kilobytes of the file, not the entire file.
I’d recommend you to use MD5/SHA-1 Hashes to check file integrity.

Okay, so the limitation only applies to items inside the container then?

I am extracting the content of the zip to verify integrity. I know too well that simply opening it and looking at the header is not enough. That’s why it’s taking so long for me to finish testing.


If you try to reproduce my video, you might still end up with valid files after restore. I tried it four times today…
There is only one scenario in witch Drobo should destroy the snapshot with 100% guarantee:
You have to fill Drobo with data, until there is less free space than the the size of the deleted file.

e.g. you create a 10GB file, make a snapshot and delete the file. You then have to fill Drobo until there is less than 10GB of free space. After that, I’ll guarantee you, you won’t be able to restore the 10GB file without errors.
If you can, then it’s fine and I’m the only one having problems with VSS :wink:

But if you can’t, please act appropriate! Send a warning to all your customers and tell them not to use VSS because it will erase data!