[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Fri, 2013-07-19 at 19:29 +0100, Philip Whateley wrote: > Thanks bad > > I'm not in the least offended and am grateful for the advice. (Any pain > from the advice would be minor compared with how I'd feel if I had (a) > lost data of real value, or (b) really needed to restore from a backup.) > > Could you also pitch in with advice on a good method for backups for > home users? I am tempted by Spideroak - not least because it can mirror > to a local disc to get a faster restore speed (which also gives some > redundancy). What would you suggest for a typical home user who is not a > sysadmin and who is not running a full home network. > > Phil > > On 19/07/13 17:47, bad apple wrote: > > On 19/07/13 16:50, Philip Whateley wrote: > >> Hmm > >> > >> Still problems: intermittently slow to mount, then wouldn't mount then > >> would mount the drive but not the volume etc etc > >> > >> Took out USB at both ends and then plugged it back in again, it mounted > >> (and faster). > >> > >> So probably the lead. I'll try a new one but I'll also look at > >> replacement drive as SMART is detecting bad sectors. At lease I have a > >> fighting chance of copying off anything remotely useful. > >> > >> Many thanks > >> > >> Phil > >> > > > > Can't help but chime in here, particularly as I'm in the middle of > > recovering two destroyed external USB Mac drives dropped off by a DJ who > > has been a 'bit rough' with them. > > > > Once again (and not for the first time I note) you've been getting > > *really* bad advice from the list on this subject, who seem to have some > > kind of weakness against disk recovery. Disclaimer: I have done a LOT of > > disk recovery, and I'm good at it to the point where literally half of > > my mortgage was paid off by some epic recovery jobs in my not so distant > > past (failed RAID array holding Â1m of architectural material, amongst > > others). > > > > First things first - backups are useless until you have tested > > restoration, as you've just found out. Only an imbecile (not picking on > > you Phil) doesn't test restoration from their backups regularly, > > especially if they're stupid enough to only have one, i.e., a half-assed > > "plug in an external USB disk every now and then and run some random > > tool". If anyone is still doing backups like this - and I expect 90%+ of > > those who even bother backing up in the first place fall into this camp > > - you're a moron, so stop it. > > > > When your disk goes south, the first thing you must do is stop randomly > > hammering it like a fool. Repeatedly re-plugging it, power-cycling it, > > hitting it with fdisk -l, remounting it, running badblocks (which > > ideally isn't supposed to be run standalone, but as part of fsck, etc) > > is obviously just stupid, for reasons I hopefully don't need to > > elaborate. Pro-tip: it just exacerbates the problem. > > > > Along with common sense, patience and experience, you will also need > > some tools to do this properly: a lot of free disk space, linux > > (obviously) and I personally have a rather expensive write-blocker kit > > because all the read-only options in the world you can pass to mount > > still won't stop any OS touching the disk anyway - particularly the NTFS > > dirty flag, amongst others. Personally, I rip the troubled disk out of > > any enclosure first, as they simply compound any issues (particularly > > anything made by WD, the most useless external disk vendor who have ever > > existed) and hook up the on-disk SATA/SCSI/SAS/IDE/etc port to my write > > blocker, which then connects to my recovery box via USB3 or firewire800. > > At this point I know that any further write backs to the disk are > > physically impossible (this is also a basic requirement for forensic > > evidence gathering; any data collected without a hardware write-blocker > > is legally inadmissible) and I can proceed to immediately dump the > > entire disk to an image file, usually via ddrescue. > > > > The disk can now be disconnected, bagged and tagged and put aside > > because after all, self-evidently, only a total moron would continue > > experimenting on a failing drive that holds the only copy of their data > > right? Right? > > > > >From now on proceed as normal with the tools of your choice, according > > to your skill set and budget. The very first thing you need to do is > > copy the original image you have just taken, and only work on the copy, > > logging every step as you go. Now at this point you may be complaining > > that this is unrealistic, as to recover your 1Tb drive you obviously > > require at *least* another 3Tb of free space: 1Tb for the original > > image, another 1Tb for the copy and you're going to need yet more space > > to dump all the recovered data once you can get at it: well, tough. You > > should see the space requirements I hit for recovering failed RAID6 > > arrays as I image individual disks and painstakingly stitch the results > > together. > > > > I'm not even going to talk about the original physical disk itself - > > SMART errors and other information all require hitting the disk (data > > recovery no-no rule 0, in case you haven't noticed) and it's presumably > > the data that is valuable to you, not Â50 worth of spinning rust. Only a > > masochist would continue to try and re-use a failed disk for anything > > remotely important after this. Sure, once all your data has been > > recovered and you're happy, you could always reinitialize the disk and > > throw it in some random box as a completely untrustworthy, throw-away > > scratch volume but why tempt fate? Bin it. > > > > There is exactly one of the above requirements/recommendations that you > > can ignore: the write-blocker. Mine is an expensive and specialist piece > > of kit, and you're not doing evidence gathering for the Police after > > all. None of the rest of it is optional: well, technically it is, but > > trust me, follow the advice or otherwise in a few more days we can > > compare notes. I'll have been paid handsomely by Mr DJ for recovering > > 95-100% of his rare groove MP3 collection and you'll be crying because > > you lost all your data because you insisted on doing stupid things, like > > hammering an already failing disk. > > > > Ok, I realise that on my usual passive/aggressive scale this email has > > been decidedly more at the sharp end, but, I don't mean to be rude or > > offend, just helpful, even if it is in a somewhat blunt and abrasive > > way. The tone hasn't been helped because this isn't the first time on > > this list I've seen absolutely idiotic "advice" given in response to > > disk failure issues. For god's sake, if anything else in life was > > exhibiting failures, even less-technical stuff like a door hinge or your > > car ignition, would you then decide it's a good idea to repeatedly open > > and shut the door again and again, or keep turning the key in the > > ignition hoping that against the rules of probability (and physics: > > entropy only increases remember), it's suddenly going to get better and > > fix itself? Of course not. So why would any moron apply the same line of > > thought to a damn hard drive, countless orders of magnitude more complex > > and delicate? > > > > And here endeth the lesson. Better put on my asbestos pants once more, I > > should think I might get a bit of flak for this :] > > > > Regards > > > > > > PS: this email was aimed at everyone, but Phil, I genuinely hope you > > manage to get your data back one way or the other. Good luck! > > PPS: I've just finished restoring the backup GPT label of disk 1 over > > the corrupted primary, resurrected the HFS+ partition and am now happily > > copying 850Gb of MP3s to safety. Working from an image of course. > > > > I just use the PCs in the house to do the work, I have the Shop user created on each of them (the kids don,t complain as the never see the login) and just alias syncdata='rsync -avs -e "ssh -l shop" shop:/home/shop/ /home/shop in each .bashrc file on each machine also to make life really easy I alias all my ssh connections as well so to connect to the raspberry pi alias raspi='ssh -l shop raspi' so just 2 commands raspi (then) syncdata & and I have a copy of everything there takes 2 seconds I do it for random machines before I logoff, rsync only transfers the changed data not the whole lot so after the first time you do it (especially on a NW of 100MBS) its fast. -- ________________________________________________________________________ Regards Kevin Lucas Minions Post Master(Sub) A dedicated Linux user /usr/bin/microsoft Skype minions_shop www.minionsbandb.co.uk www.tearooms.minionsbandb.co.uk FaceBook Minions_shop Po House, Minions, Liskeard Cornwall PL14 5LE 01579363386 -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq