I have been backing up onto a 60G ext2/3/4 partition on a 1TB external USB hard disk for a year or so now and have built up a few folders of .thunderbird, .mozilla, and other assorted files - using this as my standard "backup system" - but suddenly all the files and folders in this partition seem to have disappeared.

In Gparted and KParted the partition shows up as the correct size with the correct amount of "used space" (= yellow coloured portion), as it does when running offof any CD/standalone OS.
And the small bars under the volume names in Dolphin show about the right amount having been "used" too.
But however I try to access this partition (or, to be correct LVM I spose:-)) it still always comes up as empty - ie 0 files in it. After months of working just fine.
The NTFS partition on the same external USB sdd reads and writes quite OK/normally and also shows the correct amount of "used space" - but even from root I can't see any of the old files in, or read/write to the linux one. It comes up with "Denied"/"Can't Write to.." errors when trying to write anything to it.

I ran a freeware utility called DiskInternals Linux-Recovery from winDoze which, after half an hour, came up with a list showing all the folders and files in the partition. It said that they would be written back onto the hard drive that they were "retrieved" from - but no change happened - still no contents showing when booting up in any linux :-(

Any ideas please??
TIA
Paul W

Running a clean install of FedoraCore14 on an AMDAthlonx2 5000 (= 2.6G true) on an ASUS M2N-MX SE PLUS m/b with 2G of RAM

Here are some ideas -- they all revolve around thinking that your hardware is fine and your data is there but your drive is no longer mounting properly.
Do you think your drive is mounting? I know it is detected because you report using Gparted.

Type df -h and mount and post both here.

Where I'm going to go next with this is to start talking about /etc/fstab and making sure the drive information is correct.
(Actually LVM COULD have messed up and so is not mounting your drive ... where I'm going to go after this is to tell you
how to figure out what your drive is really called (using dmesg or tail -f /var/log/syslog) and then
use that partition name in fstab.)

Thanks for that pcardout.
Love the Galileo quote

Yes - I too wonder about it not mounting properly.
And the hardware seems to be fine - as you say it's being detected OK - and, as I say, whatever CD>RAMlinux I boot with picks it up with the same /media description and what looks like the right proportion showing as "used".
At one stage I may have had the USBextsdd thingo turned on when the machine was rebooted and I'm wondering if my "plain" bunch of ext2,3,4 folders/files got themselves converted into an LVM or PV or something like that.

And yes :-), the next "project" is to chop the enormous 500G LVM it made for itself on the "clean" install a few days ago down to something a bit more sensible/useful - didn't realise that the new installation would use everything that was available when I did it.
And AAMOI this all came about from my "upgrading" over the last few months from 12>13>14 which produced an almost worthless "Frankinstein" install - nothing much working.

Here's what came up with the commands you suggested:

df -h gives:

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_asusamd64x2boxsu120611-lv_root
50G 5.1G 44G 11% /
tmpfs 1007M 344K 1006M 1% /dev/shm
/dev/sda3 485M 47M 413M 11% /boot
/dev/mapper/vg_asusamd64x2boxsu120611-lv_home
501G 4.4G 472G 1% /home
/dev/sdb2 52G 20G 30G 40% /media/8beb71e7-6b41-4b25-a808-95c1bb3ddbf3
/dev/sdb1 879G 442G 438G 51% /media/32E13CFA21C45329

mount gives:

/dev/mapper/vg_asusamd64x2boxsu120611-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_ubject_r:tmpfs_t:s0")
/dev/sda3 on /boot type ext4 (rw)
/dev/mapper/vg_asusamd64x2boxsu120611-lv_home on /home type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdb2 on /media/8beb71e7-6b41-4b25-a808-95c1bb3ddbf3 type ext2 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /media/32E13CFA21C45329 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
gvfs-fuse-daemon on /home/Paul/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=Paul)

and dmesg came up with pages of data this being a sample of it:

[ 46.297942] SELinux: initialized (dev sdb2, type ext2), uses xattr
[ 46.583056] EXT2-fs (sdb2): error: ext2_check_page: bad entry in directory #2: : rec_len is smaller than minimal - offset=0, inode=2, rec_len=0, name_len=0
[ 46.764059] EXT2-fs (sdb2): error: ext2_readdir: bad page in #2
[ 46.764802] EXT2-fs (sdb2): error: ext2_readdir: bad page in #2

Thanks again for your help
Paul W

Your "60 GByte" partition could easily identify itself in
df -h as 52 GBytes (between the 1024-cubed vs. 1000-cubed confusion and the 5% overhead that ext3
"reserves" by default).

So sdb2 is what your external hdd partition is currently identifying as -- and I quote your df -h result here:
/dev/sdb2 52G 20G 30G 40% /media/8beb71e7-6b41-4b25-a808-95c1bb3ddbf3

As you pointed out, it is a partition on a 1 TByte drive, the rest of which shows up here
/dev/sdb1 879G 442G 438G 51% /media/32E13CFA21C45329

I friggin HATE LVM -- it makes everything so hard to read. You do not need to use it. You only need it if you want more than four primary
partitions on the same physical hard drive. If you have multiple drives, the limit is four per each.
There is no reason on god's green earth for your hard drive to be mounted in a directory
called 8beb71e7-6b41-4b25-a808-95c1bb3ddbf3. If you want to know how to set up /etc/fstab by hand, just ask.

But back to your question. Your partition is still there and mounted, but your dmesg, as you probably surmised, is packed with errors.
In such a case, fsck is recommended.

Become root. Then umount /dev/sdb2 (Type mount again and make sure it does not show up. /dev/sdb1 is safe, it's a separate partition).
Then fsck /dev/sdb2.

fsck is scary. It can fix your file system, but used incorrectly (or on a mounted partition) it can trash it thoroughly. So please do some
reading on fsck before going ahead. I think you will successfully recover this damaged partition. There is some risk, but if you do nothing, your
data is gone anyway. Let us know if it worked. If you want advice on fsck, I recommend starting a separate thread posting your dmesg output
first and asking for advice on successfully using fsck.

Before you run fsck, I wanted to make sure you had tried to look at your files from the command line.

We established that your drive is mounted, despite errors. So open a gnome-terminal and try this.

If you see some or all of your files, you are good. If you get some sort of error or you see
nothing, well, that's sort of what we expect.

That change directory line came up with

bash: cd: /media/8beb71e7-6b41-4b25-a808-95c1bb3ddbf3: No such file or directory

and your earlier suggestion of the filesystem fix after unmounting it came up with:

[root@ASUSAMD64x2boxSu120611 Paul]# fsck /dev/sdb2
fsck from util-linux-ng 2.18
e2fsck 1.41.12 (17-May-2010)
fsck.ext2: No such file or directory while trying to open /dev/sdb2

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

and the e2fsck... it suggested came up with the same.

It's very good of you to come up with these ideas.
I know that the simple way is to simply format it and start from zero again - I've got most of the important stuff backed up on other cloned sdds - and I can use the winDoze app to get at anything else that might be important, but I'm using this slightly bothersome little glitch as a way to try and develop my rather feeble understanding of the filesystem setup. Don't much enjoy it when I can't sort out things like this :-)

Maybe it's time to reformat. I am a little worried about the state of the rest of your 1 TByte drive.
Can you
If you want to understand your file system in the future. Don't use LVM, and edit your /etc/fstab yourself to read sensibly.
Here's mine.

Even if you let LVM mess up your system (and I know, it's the default for fedora, etc) you can still take control of your external
drive. The various automated tools are just doing three things.
Formatting (what cfdisk does manually).
and making a file system (what mkfs.ext3 does manually)
and then mounting (editing the /etc/fstab and executing a mount command).

Could guide you through these if you need, but you seem reasonably sophisticated, just read up on the commands and I think you can figure it
out yourself. You seem comfortable with gparted. I guess that's an OK replacement for cfdisk.

Yes - your setup looks a lot simpler and easier to fiddle with, should you need to :-)

ls -l on the ntfs partition came up with everything looking OK - and it r/ws OK too.

The 1TB USB gets very little use and was new only a year or so ago. Just had to get a 1TB when they came down to sensible prices - having started out with a type 4(?) MFM 20meg hdd 20+ years ago and thinking that that was so upmarket :-)
It's a Western Digital - which isn't all that high up the "confidence rankings" - but then, as I'm finding out, the Seagate 5yr guarantee is, in any practical sense, a bit of a waste of time - having had a couple of 500Gs become fairly terminal after about 3 years.

But when do you spose the messup with the sdb2 ext2 partition (presumably it's gotten the wrong UID or something like that) would have happened?
As you say reformatting seems to be the easy answer but it would be good to get a handle on what/when the "mistake" was :-)
My suspicion is that it might have happened when the USB sdb got (accidentally) left on when the box was booting up - and got its MBR overwritten or somehow mucked up.
It's still an ext2 partition and it hasn't gotten itself LVMed - which, like you, I'm begining to see as a bit of a pain.

Glad to hear your large partition is still OK.

I can't tell you why your 60 GB partition got messed up. There is no problem booting with an external drive turned on. I do it all the time ... it's something
you should be able to do. I think you had to actively do something (like reformat it, or remake the filesystem).

I'd be tempted to point my finger at the
Windows rescue software. I assume they knew what they were doing ... but in "rescuing" the drive, they might well have changed it to make your problem worse.

fsck is the Linux native way to fix a drive ... but in 10 years and 100 systems I have not really seen one stop reading its drive (until they flat out
crash!).

General rule is ... always have a backup. I use rsync and cron and back up one hard drive to another automatically once a week.

External drives are great (particularly blank ones) since you can use them to get
very experienced with partitioning, file-system creation, file-system repair, etc.

Since you approached this whole post saying you wanted to learn more about what worked
and what does not work, I recommend you take your external drive, make four different
partitions, format one as NTFS, one as ext3 and maybe another as reiserfs. Mount them
all write to them. Unmount them. Delete them, change them. Have a good old time.
Learn how to edit your /etc/fstab manually ... get through the scary bits about partitioning.
I agree partioning is scary ... because it is the best way to lose "all your stuff".

You'll be much happier when you understand it.
Linux hard-drive management is typically rock solid.

In your case, it looks like your internal drive is /dev/sda (and that mapper/LVM took over some of its partitions).

So long as you always work with sdb, nothing bad can happen to your real data.

I'll say good luck and goodbye on this one. Maybe other LQers who know LVM better than I can help you speculate on what went wrong.

use to get available backup blocks .
the output should look like
dumpe2fs /dev/sdc1 | grep -i backup
dumpe2fs 1.41.12 (17-May-2010)
Journal backup: inode blocks
Backup superblock at 32768, Group descriptors at 32769-32769
Backup superblock at 98304, Group descriptors at 98305-98305
Backup superblock at 163840, Group descriptors at 163841-163841
Backup superblock at 229376, Group descriptors at 229377-229377
Backup superblock at 294912, Group descriptors at 294913-294913
Backup superblock at 819200, Group descriptors at 819201-819201
Backup superblock at 884736, Group descriptors at 884737-884737


then run
And before fsck : check for correct Major/Minor numbers of the drive nodes :

1 members found this post helpful.