My bad for not replying in a tad bit, had to sort out some business.
On the topic of recovering the lost files, I dd’ed (not dd-rescue, should I try that instead?) it into an ISO, and got testdisk to work, despite the previous error. I believe I’ve had testdisk running for about 19 hours now, and it’s got 995,865 files (bytes? sectors? not exactly sure) recovered, 16 failed, out of 468,854,977. That is a HUGE difference between the amount of files recovered, and the amount of files to be copied, and keep in mind that is has been running for 19 hours. I think it got the home folder done, but nothing from /bin/, /boot/, /dev/, or /etc/, so it might be time to just stop testdisk and just rsync the rest over. I think that there is no denying that I’m in for a reinstall now, unless?
Will consider.
Sounds good to me.
No windows. Just Linux. I will attempt to get UEFI to work.
Pretty much. Looks like I’ve got no other choice. I’m pretty sure I can’t just go about deleting the boot folder, the essential binaries folder, the device files, and the configuration files for about every application on the system, and expect to just be able to fix it without any consequences. This seems like a good start, but I’m a pessimistic person, and I feel like recovery is going to take a lot more than that.
IF you have extra, spare space at least the size of your disk, or can get it, there is a chance you can recover your data using Testdisk:
I myself have used it at least twice now. Once on my own disk, when I accidentally deleted the wrong directory, causing about 1.5TB of MIA sh…tuff. It recovered it betterandfaster than someone using Windows did. Thee other time was ~250GB for family, on a NTFS partition even. If you follow the instructions to the letter it should help.
Use it to copy all your data over to the other disk, reformat this one, and copy it back. TADA!!!
If the filesystem was not being used, I don’t think it would matter, but I could be wrong. Since you started and so much time has passed, if you fail, you can retry with dd-rescue.
But one thing. dd doesn’t care about how much data is on the device, it will copy everything (if it’s empty, it might just be zeros, but dd will still copy the complete drive). Yes, if the drive is big, it can take a LONG time.
God damn it, I typed all this up and in the meantime…
Well, maybe it will benefit someone… xD
I would suggested to setup TimeShift on your new installation for the system itself, don’t do automatic snapshots they are kinda pointless, just do a system snapshot once in a while to have a recent version of the system available if needed (and manually manage your snapshots, keep one or more, delete old ones). Of course, saving the snapshots on the same disk will not help if you do that again, and delete the whole system disk, so another advice, save the snapshots on another partition or disk if you can.
For the Home folder do not use TimeShift it is a bad idea, as restoring a snapshot will remove/revert any change in the Home folder from the time the snapshot has been taken, things WILL be lost. Use other tools like DejaDup or similar, and discard folders like Downloads, Steam, Games, or other high volume folders that are pointless to backup for safekeeping.
Don’t do commands you’re not 100% sure the result will be exactly what you expect.
I disagree to that. The automatic snapshot creation that is run with the hook BEFORE system updates has saved me on multiple occasions.
And if you use stable version, you dont run that many updates so the weekly automatic snapshots also makes sense.
But you have to make sure the autodelete function is also configured so you don’t just add snapshots forever.
My point is you want to be able to restore the system in a recent working state if needed, you don’t want the system to do automatic updates by itself at random time (hourly/daily/weekly/monthly), like just before you shutdown I’m not sure what happens in this case.
What you are talking about is not the automatic TimeShift snapshots, it is the feature from an additional package timeshift-autosnap-manjaro which indeed takes a snapshot everytime you use the package manager.
In my opinion any automation for the snapshots, unless you use BTRFS, is not practical, as it hogs the system when you probably don’t want to, and the manual snapshot before a big update is just enough for the normal user to revert back a big update if needed or to get back to working state if you break the system. If you tinker a lot with the system I think the manual snapshot is still the better option, as you can just take a snapshot when you know you’re probably going to break the system.
You mean if he reinstalls without using btrfs? Sure, then I agree.
But I was under the assumption that more or less everyone in the thread recommends using btrfs in the new install…
Testdisk just finished. Nothing from /bin/, /boot/, or /etc/. Unless there’s a miracle, I’m reinstalling tomorrow. It was fun while it lasted, Manjaro Installation the 1st.
