System rebooted unexpectedly with a USB drive attached - now I cannot remount said drive.

[osprey]

I am also a bit confused: there have been multiple recommendations to not do any work on the external disk, as that could further impact in my ability to recover the data - but there are then recommendations to perform work on the disk.

Is this to say that filesystem check (fsck) won't cause further complications - and if not, what work should I avoid doing on the drive? I can't mount the drive, so it isn't as if I can write data to it, so I am getting confused.

If the dd command shown in post #18 is correct, then there appears to have been a transcription error in post #16. If so, that resolves that issue.

On the matter of doing "work" on the external drive, these are the considerations that matter, as I understand them:

There's data you wish to recover from the external drive.
In post #16 you mentioned that the command blkid could see the drive.

Now, given those facts, if you use recovery tools like testdisk or photorec, they are used without mounting the external drive. If the external drive is not mounted, nothing is changed on it, rather it is merely read by the tools, and not altered. Hence any concern about messing up the external drive more than it is, can be dispelled because of the way these tools work. In fact, the tools testdisk and photorec don't read at the filesystem level, rather they read at the lower level of the disk itself directly on the block device.

There are several ways of using the tools: 1. from a live disk or rescue disk which contains them, or 2. from having them installed on the existing installation if it's working properly. If the installed system is not working perfectly well, then use a live disk.

Often in such situations, the advice is to make a byte-for-byte copy of the disk that holds the data that the user wishes to recover, and work with recovery tools on that copy of the disk. That's an extra precaution and protection, and something you could consider, but you'd need another 5TB disk to do that, and it doesn't appear necessary in this situation as I understand it.

On the matter of whether your work on the /var directory or partition played a role in the problem with the external disk, it is still unclear. If /var was on the installed system and not on the external disk, then the likelihood of the /var directory activities disabling or causing malfunction of the external disk is remote to say the least. If the /var directory was on the external disk, that's a different matter, hence the request for the output of the two commands: lsblk and blkid, as root, with the external disk plugged in, suggested in post #17. They will hopefully show the disks and the mounts and provide more context. I hope this clears a few things up.

 

[Condobloke]

There are several ways of using the tools: 1. from a live disk or rescue disk which contains them, or 2. from having them installed on the existing installation if it's working properly. If the installed system is not working perfectly well, then use a live disk

@Priest_Apostate, hence my comments in post #2

 

[Priest_Apostate]

OP,

In your other Thread..you were saying you wanted to "clean" out var and I said you shouldn't touch System Files...leave them be...remember ?

In this Thread you say...you were "cleaning" var and the computer shut down...more like the Distro shut down because what you did in var...looks like the chickens have come home to roost.

I didn't get far into that, @bob466 - _no files were deleted: at the time the shutdown occurred, I was searching through the various directories and log files in /var/log to find out which would be the least impactful to either move, or delete when the shutdown occurred.

 

[Priest_Apostate]

If the dd command shown in post #18 is correct, then there appears to have been a transcription error in post #16. If so, that resolves that issue.

On the matter of doing "work" on the external drive, these are the considerations that matter, as I understand them:

There's data you wish to recover from the external drive.
In post #16 you mentioned that the command blkid could see the drive.

Now, given those facts, if you use recovery tools like testdisk or photorec, they are used without mounting the external drive. If the external drive is not mounted, nothing is changed on it, rather it is merely read by the tools, and not altered. Hence any concern about messing up the external drive more than it is, can be dispelled because of the way these tools work. In fact, the tools don't read at the filesystem level, rather they read at the lower level of the disk itself directly on the block device.

There are several ways of using the tools: 1. from a live disk or rescue disk which contains them, or 2. from having them installed on the existing installation if it's working properly. If the installed system is not working perfectly well, then use a live disk.

Often in such situations, the advice is to make a byte-for-byte copy of the disk that holds the data that the user wishes to recover, and work with recovery tools on that copy of the disk. That's an extra precaution and protection, and something you could consider, but you'd need another 5TB disk to do that, and it doesn't appear necessary in this situation as I understand it.

On the matter of whether your work on the /var directory or partition played a role in the problem with the external disk, it is still unclear. If /var was on the installed system and not on the external disk, then the likelihood of the /var directory activities disabling or causing malfunction of the external disk is remote to say the least. If the /var directory was on the external disk, that's a different matter, hence the request for the output of the two commands: lsblk and blkid, as root, with the external disk plugged in, suggested in post #17. They will hopefully show the disks and the mounts and provide more context. I hope this clears a few things up.

Thank you - that greatly clears up the confusion.

If I am correctly understanding what you're saying, I should be able to theoretically use different file recovery programs (that is, if - and only if - the ones mentioned in this thread don't work).

 

[Alexzee]

1. less than a year old - it is a Seagate. As you asked about it being a Seagate, I checked for Seagate specific tools, but couldn't find anything, @Alexzee - why did you ask about the brand?
2. I've been poring through the dmesg log file - but can't find anything that would indicate an issue.
3. I've been researching about journals and systemd references for information on how to attempt to investigate further.
4. I'm running memtester now, on 9GB out of 16GB (10 GB was free, so I figured on saving 1 GB to spare) - I'm on Loop 3, and no issues have come up yet.

I asked about the brand because Seagate Hdd's did have problems about 3-4 years ago.

FWIW, any time that I ran Memtest and the RAM was bad it was detected very quickly. That is within the first 10 to 20 minutes.
I'd still wait until the program finishes.

Testdisk

Partition Recovery and File Undelete

TestDisk is a free and open source data recovery software tool designed to recover lost partition and unerase deleted files.

www.cgsecurity.org

 

[Priest_Apostate]

In case anyone is curious, after working with TestDisk, I wasn't able to save the data from the hard drive - and said hard drive is now bricked. grins I'll have to experiment with that further!
Live and learn - thanks for everyone's help and suggestions, though!