I've had a SSD fail after 2 weeks. Since it was a brand new machine, I hadn't made any backups yet. Grrr... The new SSD is now 12 years old and I have a versioned backup system. So, losing data due to no or incomplete backups, happens to everybody and the only way to avoid it, is through great diligence right from the start. When you switch a machine on for the first time, you should put a backup method in place. BTW, messing with partitions is almost a sure fire way to lose data. Don't ever do that. Plan the system properly and then leave the partitions alone. If you really have a bad mix of partition sizes, then you can usually work around the issue with soft and hard links.
Last edited by HermanAB; May 19th, 2021 at 06:33 PM.
Cheers, Herman http://www.aeronetworks.ca
Originally Posted by HermanAB So, losing data due to no or incomplete backups, happens to everybody and the only way to avoid it, is through great diligence right from the start. When you switch a machine on for the first time, you should put a backup method in place. Testify! Nobody is perfect. I can admit that I've brought up 3 new systems the last few weeks and did not setup **any** backups for them at all. They are toy systems - a 21.04 desktop and (2) 21.04 servers. The server installs were mainly to see the installation options, though I did put both into my LAN DNS, gave them carefully selected IPs, and pushed some ssh-keys over. The 21.04 Gnome3 Desktop install has already been wiped. It was crazy bloated and using too much storage. My VPN server doesn't have backups yet. Since it doesn't have any data, just self-created certs, rebuilding it from scratch would take about 20 minutes, maximum. QR-codes make transferring client-side credentials much easier. But for my real systems, those that will have important data or important data processing, then having a basic backup very early in the deployment is important. All the backup scripts are nearly identical, with slight changes for hostnames, directories to be included, pre-backup and post-backup scripts to be run. Each is very similar, but not quite the same.
"Error fsyncing/closi ng /dev/sda1: Input/output error" This is what GParted is showing. I can't do anything! Edit: I was on the Live USB of Ubuntu 20.04 LTS.
Last edited by amjjawad; May 31st, 2021 at 11:05 AM.
Update: In BIOS Hard Disk: [Not Detected]
"He's dead, Jim." Hopefully, you got all the data off as suggested many times above before the failure. If not, you'll need to decide how much you are willing to pay for someone in the data recovery industry to replace the internal drive controller and attempt to restore it. Around here, that isn't hundreds of dollars, but thousands of dollars. Perhaps the $40 for a cheap external USB backup disk seems like a bargain at this point. You could still remove the drive, put it into a $20 USB disk enclosure, connect it to another system, and maybe gain access to the data. Just depends on where the problem is - in the motherboard or in the disk or in the cabling that connects them. Each is bad, just in different ways.
Wait, how come it's dead and I still can see GRUB Menu?! Yes, BIOS couldn't read it but when I boot normally, I can clearly see the GRUB Menu. However, when I see (initramfs), no commands can be found, not even sudo!
initramfs is a limited shell. Only very specific commands are available. As to the other question, IDK.
After nearly 2 months, I'm here to report that, the laptop is [still] doing crazy stuff. I did a full test for each and every single part of the laptop. I couldn't find out what is going on? I thought, after using an old Hard Disk Drive instead of the one that is full of [Bad Sectors] which, no matter what I did, I failed to retrieve one single byte; I thought the problem was the [HDD with bad sectors] but, guess what? I'm running the laptop now for two days [WITHOUT] any HDD. I'm booting from a LiveUSB that has Ubuntu 20.04 LTS. I think, most likely, the problem [was] the Operating System, not the actual HDD itself. The [exact same behavior] happened to the laptop with another HDD. I thought, the 2nd HDD is going to die as well. I did more than one test and there is not even one single bad sector whatsoever. Same behavior: Laptop Freezes. I can't do anything unless turn it OFF from the [Power Button] and when I turn it ON again, well, [Freeze] again. RAM test for 2 days = all good. Laptop is running LiveUSB with Ubuntu 20.04 for 2 days = all good. While I'm not an expert to confirm that the problem was the [OS] which was Ubuntu 18.04 but, at the same time, I can't think of any other cause. I can't blame the OS for damaging my HDD, which was [NEW] and I was using it super carefully. However, I can't think of any other cause! The damage is done, period. My HDD is full of bad sectors. I don't have thousands of dollars to try to pull the data out. I've being using Ubuntu and its official variants since 2010, never ever seen the exact same problem. The moment I started to use Ubuntu 18.04, I have faced many issues, to name the last, the one that I reported in this thread. I feel bad and sad.
Last edited by amjjawad; July 28th, 2021 at 11:56 AM. Reason: Typo
http://torios.top
My HDD is full of bad sectors. I don't have thousands of dollars to try to pull the data out. If you are willing to gamble about $90 (I repeat, gamble) I have read that a very old app SpinRite at grc.com has provided HDD recovery for some enthusiasts. But only from what I have read. I have not gambled myself on this product. Perhaps post a message to the creator of SpinRite with a summary of the problem. A money back guarantee I would try. [P.S.] Some further references to SpinRite posted here. [P.P.S] Further idea. Install R-Linux in your LiveUSB (which seems to work) then follow guide here to examine drives with bad sectors. The only problem with this idea is that installing apps into LiveUSB is not persistent and you will have to reinstall each time you boot up LiveUSB. But it costs nothing to try. [P.P.S] Referring to post #9 did you try without options? (i.e., without -a or -p options) ubuntu@ubuntu:~$
Last edited by dragonfly41; July 28th, 2021 at 03:21 PM. Reason: added some ideas ...
I've had spinrite for decades. It violates all sorts of "do no harm" requirements that data recovery experts follow. It is also limited to 2TB, since it doesn't do GPT. It has been about 15 yrs since I used spinrite. It is basically like ddrescue, badblocks and normal versioned backups. If we do normal backups using tools that validate the source partition data can be read, then we've exercised the storage areas and provided the HDD drivers a chance to relocate any lazy bits. Don't use spinrite on flash storage or SSDs.
View Tag Cloud
Ubuntu Forums Code of Conduct