hi guys ive seen some posts throughout the board, where it’s been pointed out that if you delete something on a windows drobo, (eg actual delete/empty from recycle bin), that you cant undelete due to new files being given randomly allocated free blocks or similar…
a) i was wondering if this is 100% of the time, (or almost always which is effectively as bad as 100%)
b) is this the same with large fixed-size files?
(eg, if you had a truespace fixed-length container, and when mounted, if you deleted a file from it, is it the truespace program which manages the deletions or the drobo?
the theroetical idea is that maybe we could create 2 such containers (one for backups in case it has problems etc) and to then be able to successfully use undelete tools to recover some files (in addition to the virtually mounted recycle bin that the encrypted volume could have)
a) it almost certainly will be i would expect - the block will be marked as free by drobo, which means i doubt it would bother maintaining the records of where they were
b) if its a fixed sized encrypted container - then drobo is just protecting that one fixed size file - so drobo will maintain all of the blocks - so this will be no different to trying to undelete something from an encrypted container on a fixed disk - i just dont know whether that is possible as it may be that by deleting something from an encrypted container, it is automatically overwritten by the container/truecrypt - i have never tried. saying that i dont know if a recover program can even access the container ?[hr]
also, i dont see the point of what you are trying to accomplish?
if you want a backup - then just make a backup?
if you ALWAYS want to be able to recover deleted files - then why not stop deleting them and just create a folder called junk and simply move the files to there rather than deleting them?
you could even set up a little script so that anything in the junk folder for more than 30 or 60 days is automatically really deleted?
On my synology (which is a NAS) it has an option for a CIFS recycle bin - any files deleted via network access arent actually deleted, they are just moved to a recycling folder so its easy to get them back
i was browsing some older posts and was just wondering about it
(i’ll try it out sometime too to see if the theory works, after the rebuild project is complete)
Based on my Volume Shadow Copy testing a while back…
a) Not 100% of the time, it’s unpredictable, but that’s even worse in this case. So take it as “No, can’t happen, don’t do it.”
b) Yes, same thing. It’s just more blocks, so higher likelihood of at least one of them being different and therefore getting a corrupt file from re-linking (normal un-delete) to an unallocated block.
That said, Previous Versions (which is based on VSC) works if and only if you don’t delete the file. As long as the file lives, its original blocks live and you can follow the trail-of-changes to the file.
I like the idea of just moving stuff to a Junk folder. That’s essentially what Undelete from Condusiv (formerly known as Diskeeper, fka Executive Software) does, though it also gives you some additional previous version support that isn’t reliant on VSC.
IMO for a readily-accessible (I’d say online in terms of online/near-line/offline but it gets confused with Internet/cloud-based stuff nowadays) backup, I’d consider one of the many synchronization tools to do file-based syncs/archives to a specific folder.
This is a really interesting discussion. I think the difference is between virtualized filesystem vs. virtualized block device.
Because Drobo virtualizes the filesystem, undelete cannot be reliable. I imagine that flash storage with TRIM is similar in this respect.
If you create a virtual block device on Drobo, then undelete might work. Mac’s sparsebundle, an iSCSI virtual disk (e.g. using Starwind’s target software), Virtual Machines, or products like TrueCrypt create their own “internal” filesystems.
Any “filesystem-within-a-file” is safe, as long as you don’t delete the container file.
On the SSD side, a very similar result (undelete completes, but may return corrupt content) happens due to TRIM and wear-leveling. A request to a arbitrary block on an SSD is not guaranteed to map to the same memory cell after it’s been released (TRIM-ed), as wear-leveling may have remapping that logical block number to a different (physical) memory cell.
It’s difficult to abstract, but imagine a traditional hard drive is like a writing with a pencil in a hard-bound notebook.
You write on page 1…
You write on page 2…
You write on page 3…
You decide to erase page 1.
You take an eraser to the entire page and erases it.
You change your mind and want page 1’s contents back.
You get page 1 and because you hadn’t written on it a second time, you can still see the impressions and figure out what it said.
Now SSD with trim and wear leveling, it’s a bit different.
You’re still writing with pencil, but it’s more like a binder with separate sheets of paper.
You write on page 1…
You write on page 2…
You write on page 3…
You decide to erase page 1.
Your assistant knows if you continually write and erase the same paper it’ll develop a hole.
So your assistant flags page 1 from the binder to be used later* (TRIM) and swaps it with a brand-new page from elsewhere in the binder (wear-leveling).
You change your mind and want page 1’s contents back.
Your assistant provides you page 1 and you look at it carefully for impressions, but there’s nothing there because it’s a brand-new page that has never been physically written to!**
The assistant, or middleman virtualizer and its wear-leveling is what screws things up in a traditional undelete since the old page you request isn’t necessarily the same page you had before.
Technically, when the page is re-used it never gets erased, it just gets overwritten, but the concept has no real analogy to pencil-writing unless someone’s invented a pencil with a flying erase head.
** Technically the data still exists on the page until the page gets re-used, but there isn’t a way for traditional undelete to request that specific page because it uses page number, which has been virtualized by the assistant, and TRIM-ed pages are supposed to return zeroes or a fixed pattern rather than the actual content.
In theory an SSD-aware undelete application might somehow be able to tell the assistant to get the page that used to be page 1 and request the data from the original block, but that goes against features like Secure Delete and would require some amount of history on the wear-leveling, which means extra processing and slowdown on the SSD controller.
(i didnt know that free blocks can be used crossed volume, i guess it makes sense)
(i also didnt know about Trim rdo until now, i thought it was just what you ask a barber to do)
nice pencil writing analogy too - “if it wasnt for those pesky assistants”
For SSDs, wear-leveling is often mentioned in the marketing bullet-points. Early SSDs has poor/little/no wear-leveling which led to early burn-out. Now it’s standard on SSDs at least.
For spinning platters, not sure what kind of intelligence is applied. I’ve always assumed that save for reallocated spare sectors, the logical geometry followed the physical geometry pretty closely, but that’s just an assumption.
Generally, flash-based devices (SSDs, SD cards, etc.) do and straight HDDs (with no fancy virtualization layers) don’t. It’s just an inherent feature of flash-based media that you can perform only so many writes to the same physical cell before it wears out.[hr]
Sorry bhiga, somehow I didn’t see your post only after I sent mine.
thanks, ive been using tip on zip disks to check which ones are still ok,
was thinking maybe something might be needed (a bit like data/data area scrubbing) which spinrite uses on some hard drives, but on a flash device to keep it in good shape, but chances are you wouldnt be testing the same sector if its all randomised with wear levelling.
(actually for some reason, i keep thinking of the word “data scrubbing” as deleting data, when in actual fact it’s more about verifying it
Though they interface the same, SSDs and spinning disks have much different care & feeding needs.
Many of the typical maintenance tasks that apply to HDDs don’t apply or may even be detrimental to SSDs.
Read/Write testing, non-SSD-aware defrag…
Similar to how we moved from “dumb” drives that required drive-specific controllers to IDE with standardization via abstraction, modern SSD controllers are very intelligent.
Not sure where the “scrubbing” term comes from - it’s also used for the same process in RAM… I bet someone here knows though!
(btw ive seen people mention ssd-aware software, or ssd-aware undelete, ssd-aware defrag…
maybe when turned around, the ssd should be app-aware eg defrag-aware ssd, etc
