Matt Harrison wrote:
I know this may have been discussed before but my google-fu hasn't
turned up anything directly related.
My girlfriend had some files stored in a zfs dataset on my home
server. She assured me that she didn't need them any more so I
destroyed the dataset (I know I should have kept it anyway for just
this occasion).
She's now desperate to get it back as she's realised there some
important work stuff hidden away in there.
Now there has been data written to the other datasets, but as far as I
know, no other dataset has been created or destroyed.
Is there any way to recover the dataset and any/all of the data?
Very grateful someone can give me some good news :)
First observations, then suggestions...
I know people who have had variations of this scenario happen:
Person says they have everything they need but actually forgets about
something, doesn't notice it was misplaced in a different folder, or
doesn't check other folders. Computer is restored/rebuilt/reimaged.
Some data lost.
Admin makes backup of filesystem to another computer. Rebuilds server.
Attempts to restore backup but discovers backup was
incomplete/corrupt/failed silently. Some data lost.
Person moves data to a shiny new external hard drive. A week later the
external drive gets knocked over and dies. One computer the data was
copied from has already been wiped in preparation for reuse. Some data
lost.
One way to prevent the first case is to get the user to go through all
their files and explicitly delete the files themselves. Another is to
go in after the user and look for content that was likely overlooked. A
third is to back it up anyway, even if they didn't say anything was
needed. I've heard of computer stores doing this: offering a for-fee
data backup service when they repair a PC/replace a drive, if the
customer declines the service, the data is still backed up (to protect
the company from accidents on their end), and the job is completed. If
the customer returns within one week to say "I forgot about x, y, and
z...can you recover it?" the company still has the backup that they can
offer it to the customer for a fee higher than the original backup
service fee (consider data recovery fee levels).
In the second case, verifying that you have a working backup procedure
is key. If you aren't making backups and just want to migrate data to a
new system, bytewise or strong hash file comparisons can catch a lot of
problems. On Windows systems, the free Windiff tool works well. It
also runs fine under Ubuntu via Wine.
The third case demonstrates data vulnerability, single points of
failure, and user unfamiliarity with external storage devices. This
user now makes backups of his/her most important data to high grade
DVD+R media and keeps copies out of state. (I've heard of people using
the postal services as a defacto off site backup by mailing a DVD every
day to a friend across the country. When the friend receives it, they
open the package, take out a preprinted postage label, apply it to the
front, and drops it back in the mail to the original person. Thus, the
original person has backups in transit all the time and always has one
on its way back to him. If there were a catastrophic site failure site
such as an uncontrolled wildfire, the postal service would be able to
hold the incoming mail for a few days until further plans are made.)
Suggestions:
You can try a recovery tool that supports file carving. This technique
looks for files based on their signatures while ignoring damaged,
nonexistent, or unsupported partition and/or filesystem info. Works
best on small files, but gets worse as file sizes increase (or more
accurately, gets worse as file fragmentation increases which tends to be
more of a problem as file size increases). Should work well for files
smaller than the stripe size. Small text based files have the best
chances for recovery (e.g. TXT, RTF, HTML, XML, CSV) while more complex
and large formats break more easily (e.g PPT, XLS, JPG).
Do not use the array, and disable or otherwise do not run scrub or any
other command that may write to the array until you have exhausted your
recovery options or no longer care to keep trying.
If you had a redundant ZFS system on multiple disks, you may need to run
the file carver on each disk individually to find what is missing. If
this was a ZFS mirror, either disk will likely work, but if it was a
RAIDZ1 or RAIDZ2 you will almost certainly need to scan all the disks
that were in the array, because you won't know in advance which disk
will have the original data and which will have the parity for any given
file.
If you had compression and/or encryption enabled, standard file carving
won't get you very far, as the raw disk sectors won't contain the
patterns the file carver is looking for. In that case you'd need a data
recovery application that can handle ZFS compression formats and/or ZFS
encryption (plus the passwords/authentication) that can then either
present the ZFS filesystem as a block device to a file carving tool or
can scan for ZFS directory structure remnants. I don't know of any such
tools myself.
Tools: EasyRecovery supports file carving as does RecoverMyFiles, and
TestDisk. I'm sure there are others too. Not all programs actually
call it file carving. The effectiveness of the programs may vary so it
is worthwhile to try any demo versions. The programs will need
direct/block level access to the drive...network shares won't work,
although I believe iSCSI theoretically should You can run the recovery
software on whatever OS it needs, and based on what you are asking for,
you don't need to seek recovery software that is explicitly Solaris
compatible.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
