Return to BSD News archive
Xref: sserve comp.unix.admin:18877 comp.unix.internals:7113 comp.unix.misc:12070 comp.unix.bsd:13778 comp.unix.ultrix:22213 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uknet!EU.net!news.eunet.fi!prime.mdata.fi!mits!jaittoko From: jaittoko@mits.mdata.fi (Jari Aittokoski) Newsgroups: comp.unix.admin,comp.unix.internals,comp.unix.misc,comp.unix.bsd,alt.unix.wizards.free,comp.unix.ultrix Subject: Re: BIG TROUBLE : PLEASE REPLY IF YOU CAN !!!! Followup-To: comp.unix.admin,comp.unix.internals,comp.unix.misc,comp.unix.bsd,alt.unix.wizards.free,comp.unix.ultrix Date: 28 Apr 1994 15:59:01 GMT Organization: Microdata International Telecomm Service, Helsinki, Finland Lines: 50 Message-ID: <2pomg5$lmj@prime.mdata.fi> References: <CovK53.DCM@isosa2.estec.esa.nl> NNTP-Posting-Host: mits.mdata.fi X-Newsreader: TIN [version 1.2 PL2] Christophe Arviset (carviset@isou20.estec.esa.nl) wrote: : Very important files were backed up (using rdump 0uf) on a file on disk. : By doing various (and inconsiderate !!) manipulations, a mistake was done and : the dump file became empty. Most probably, due a redirection error, the dump : file content was set to zero. : The file system where the dump file stands has been umounted and nobody could : write on it. : May be the file has not been physically erased, but just the first byte was : set to null and therefore, the content of the file still lays on the disk but : can not be seen with the normal UNIX commands. : DO YOU KNOW ANY WAY TO RECOVER THE CONTENT OF THE DUMP FILE ? : I would appreciate any kind of help... : Christophe ARVISET All your data will be intact on the disk. I dont know, how to restore the dump file to 100% condition, it would require some lo-level hex-editing, but at least your data can be read from the disk. Depending on the size of your disk, you can copy it to another disk by lets say: dd if=/dev/rrz3b ibs=1024k of=/home/disk3b.save. You can pipe it through "strings", if your data is pure ascii (it will still drop empty or very short lines). After copying you can split the huge file into manageable pieces, and using "egrep" locate the pieces, where you should start looking for data. If you have lots of memory, you can read the file into emacs or vile -editor. Of course, if its some binary data, these won't help. Probaply the least amount of work is done, if you restore the last saved backups. If you are lucky, you can find the backup header and depending on how fragmented the disk is, at least some part of the file. Using dd you can manage also big files using "bs=xxx" "skip=xxx" and "count=xxx" options. There are companies, who are specialized doing disk recovey, your insurance company could know. But it will cost... I Hope this will be any help! Jari Aittokoski, Helsinki Finland - jaittoko@mits.mdata.fi