loss of data in opensuse

ungua · 01-11-2008, 04:04 AM

i have several times observed a loss of data in my /home/ungua/documents-folder. i remember very well that for some time ago all my files in "bank documents" disappeared, the folders being in place but empty. in my archive for reports and the like i just discovered that the complete folder for html-folders is empty but one report. all folders are in place again, but they contain 0b of information, no files. what the fuck happened there!?!? i do backups regularly, but how am i to trust the software when i never know what data "survives"?? i have done nothing to these folders, i just use them very infrequently. but i often work offline and on travels with my notebook and need access to these reports from time to time...

best regards
ungua - who once switched from windows to linux for data safety

marozsas · 01-11-2008, 05:37 AM

I don't think this is a software fault.
I am using openSuSE in a enterprise environment, as a busy fileserver, printer server, postfix, imap courrier, and database server (Firebird), with hundreds of simultaneous users, and we never - ever, had any problems in theses 2 years or so. We have a good piece of hardware: a Dell PowerEdge 2950 with SATA disks in RAID-5.

Looks like a hardware fault.

Look for IO errors in your log files.
Just in case, check for filesystem errors too (put the machine in single mode and run a fsck -f in every partition)

ungua · 01-13-2008, 07:44 AM

thank you for your advice! i am really not into how-it-works in linux, what log-files do you recommend? what is "single mode"? i just googled it but i didn't really find a good explanation. super-root??

regards
ungua

marozsas · 01-14-2008, 05:01 AM

I'm sorry. Here the dirty details....

The messages are in /var/log/messages. Due to log rotation process, old messages are in /var/log/messages*.bz2 in compressed format.

To find a string in message file you can use "cat /var/log/messages | grep -i disk".
To find it in bz2 compressed files, use: "bzcat /var/log/messages*.bz2 | grep -i disk".
The "-i" makes grep case insensitive.

I don't have a disk error message in my system, so I don't recall what is the right string to search for.
But a combination with "disk" and "error" should work. You can search for lines with "disk" and "error" using something like this: "cat /var/log/messages | grep -i disk | grep -i error"

The other think I mentioned is to force a check in your filesystem.
To do that, bring your system in single user mode. To do that, one way is run the command "telinit s". After that, umount the suspected file system, let say "hda6" with the command "umount /dev/hda6" and force a check with "fsck -f /dev/hda6". Repeat this procedure to all filesystems. Reboot your system at end.

Another way is to create a empty file at root of filesystem ("touch /forcefsck" to root filesystem; "touch /home/forcefsck" for the home filesystem; I don't know how many filesystem you have. to check, run "df -lk" and check the column "mounted on) and reboot your system. At next boot it will check the filesystems you flagged.

see'ya,

ungua · 01-16-2008, 12:27 PM

thank you for your excellent guide!

it doesn't seem to be any hardware failure, log result is "no comment" -

Code:

ungua:~ # cat /var/log/messages | grep -i disk | grep -i error
ungua:~ # bzcat /var/log/messages*.bz2 | grep -i disk | grep -i error
ungua:~ #

- which i assume is good. the forced check of the file system returned no failures either. it should write a log into "stdout", but this file contained new information after the reboot so i cannot post the exact statement here. you have used a lot of time on my problem already, but do have any other idea what could be the cause of it? i am 100% sure that i didn't delete anything in those folders where files disappeared.

best regards
ungua

marozsas · 01-16-2008, 12:43 PM

Well, I don't have other explanation.

May be the files are not deleted, just "hidden" in another location in your hard disk ?
Do you remember the name of a few missed files ? even partial names ? You can search for files, specifying partial names using a command line like this (as root user to avoid permission issues):

Code:

# find / -type f -iname "*partialfilename*"

Don't use paths in the specification; just partial filenames. Try to not be too specific at first search to improve the chances to find something useful.

I hope you can manage to find something.....

ungua · 01-16-2008, 03:36 PM

thanks again! i didn't find the exemplary file i was searching for (the remaining folder has still the same name as the report), but there was an error message:

Code:

ungua:~ # find / -type f -iname "*report name*"
find: /proc/4249/task: No such file or directory
find: /proc/4249/fd: No such file or directory
find: WARNING: Hard link count is wrong for /: this may be a bug in your filesystem driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.

i get the same error message if i repeat the command. may a corrupt "filesystem driver" be responsible for disappearing files, too? i'd very much like to upgrade to suse 10.3 but i'm afraid i don't have time and patience until easter or something...

regards
ungua

marozsas · 01-17-2008, 04:08 AM

Quote:

Originally Posted by ungua

may a corrupt "filesystem driver" be responsible for disappearing files, too?
ungua

Sure ! This why I suggested you to force the file system check !

I am wondering why the file system check didn't fix it. May be you didn't specify the right filesystem ?

What is the output of "df -lh" ? with this output I can give you the exactly command lines to check the filesystems.

ungua · 01-17-2008, 02:53 PM

this is weird! it was hda7 i forced the filecheck on, i tried that on all partitions but it wouldn't work with ntfs, of course.

Code:

ungua@localhost:~> df -lh
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda7              24G   23G  814M  97% /
udev                  376M  168K  375M   1% /dev
/dev/hda1             4,9G  4,6G  351M  93% /windows/C
/dev/hda5             7,9G  6,3G  1,7G  80% /windows/D
ungua@localhost:~>

is there a different outcome of

Quote:

The other think I mentioned is to force a check in your filesystem.
To do that, bring your system in single user mode. To do that, one way is run the command "telinit s". After that, umount the suspected file system, let say "hda6" with the command "umount /dev/hda6" and force a check with "fsck -f /dev/hda6". Repeat this procedure to all filesystems. Reboot your system at end.

than

Quote:

Another way is to create a empty file at root of filesystem ("touch /forcefsck" to root filesystem; "touch /home/forcefsck" for the home filesystem; I don't know how many filesystem you have. to check, run "df -lk" and check the column "mounted on) and reboot your system. At next boot it will check the filesystems you flagged.

? because i only tried the first one.

thank you, again, for your time!!

regards
ungua

marozsas · 01-18-2008, 05:07 AM

Yes, you have only one linux filesystem at /dev/hda7.
This could be a problem, because the tool to fix the filesystem (fsck) is in the same filesystem you are trying to fix.
And the filesystem needs to be umounted to this succeed.

Anyway, try the second way. As root, "touch /forcefsck" and reboot your machine.
At boot time, fsck will be forced to check /dev/hda7.
I am not sure what will happen next. I don't know if it will possible to run fsck on / (you may get a read only filesystem message...)

If there are any errors it can't handle, it will ask the root password and a root shell will be opened, and you need to run fsck interactively on that partition. If is the case, the command "fsck -f /dev/hda7" may ask for actions to fix the partition. Basically it will ask if it can delete zero sizes entries and things like that.

If fsck can't fix the system because it is mounted (read only), try to boot from a live CD or from the installation disks, and choose the repair mode.

Boot with the SuSE 10.1 installation disk (1/5). At the initial screen, choose Rescue System. (this is odd - I think I am seeing a Easter Egg or something like that - I am seeing tux in a snowing landscape...cool...)

At rescue login prompt type "root", no password.
At this point you can run "fsck -f /dev/hda7".

On a ext2/ext3 filesystem (check yours with "file -s /dev/hda7") you can make a additional test, scanning the partition for read/write errors with "e2fsck -cc /dev/hda7". It can take hours to complete but you can be sure your disk is ok.

ungua · 01-23-2008, 04:38 PM

... it took some time since i did some backups and have a lot of work to do at the moment.

the "touch /forcefsck"-command didn't do anything that i recognised, rebooting took about as long as always and the bootlog didn't contain anything like the "fsck -f"-command produces (that works read-only and finished without errors*).

i am abroad due to work until medio-february, so i cannot access my 10.1 cd's - so i downloaded the "SUSE-Linux-10.1-GM_Remastered-i386-CD1.delta.iso" but k3b didn't identify the "kind of iso"* or what it's called in english - i forced it to use "iso9660" and burning the cd worked. but the cd wouldn't work. i installed my current os in august '06 so i guess it is not the "remastered" version anyway... can i execute those commands also from another live-cd? i have knoppix 5.1 with me.

"file -s /dev/hda7" results in the following: "/dev/hda7: x86 boot sector, code offset 0x48".

best regards around the globe!

ungua

marozsas · 01-24-2008, 04:53 AM

Quote:

Originally Posted by ungua

... it took some time since i did some backups and have a lot of work to do at the moment.

the "touch /forcefsck"-command didn't do anything that i recognised, rebooting took about as long as always and the bootlog didn't contain anything like the "fsck -f"-command produces (that works read-only and finished without errors image.

Nice image !
I can recognized some important things from this image:
Your filesystem is ReiserFS (due to reisersfsck command) and the forced fsck worked (due to message "Do you want to run this program" and the reiserfsck output).

Quote:

Originally Posted by ungua

i am abroad due to work until medio-february, so i cannot access my 10.1 cd's - so i downloaded the "SUSE-Linux-10.1-GM_Remastered-i386-CD1.delta.iso" but k3b didn't identify the "kind of iso" k3b or what it's called in english ....

This is a DELTA (differential) image, not the whole stuff. With this delta and the original you can "re-master" a updated image.

Quote:

Originally Posted by ungua

can i execute those commands also from another live-cd? i have knoppix 5.1 with me.

"file -s /dev/hda7" results in the following: "/dev/hda7: x86 boot sector, code offset 0x48".

best regards around the globe!

ungua

Your filesystem is a reiserFS and I don't think Knoppix will have the reiser tools you need to check this filesystem. As far I know, only SuSE boot cds has built-in support for reiserFS.

and I can't explain the "file -s" output; I expected a file system type, not "x86 boot sector" which is typical for boot sectors, like this from my personal computer. weird...You got only that short message or an extended message like mine ?

Code:

[root@babylon5 ~]# file -s /dev/sda1
/dev/sda1: x86 boot sector, code offset 0x4a, OEM-ID "Dell 8.0", sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 63, heads 255, hidden sectors 63, sectors 64197 (volumes > 32 MB) , serial number 0x7d60a06, label: "DellUtility", FAT (16 bit)
[root@babylon5 ~]#

I suggest you boot your computer with the SuSE disks in repair mode and try to run fsck in interactive mode to be sure your filesystem is free of errors. My hint about running "fsck -cc" is not valid for reiserFS. And the real command is not "fsck" or "e2fsck", but "reiserfsck".

From the first image, I can't say if are any errors in the reiser filesystem, because it is an image "in progress".

well, I'm still here and I hope I can help you to fix your system when you go back to home.

Have a nice trip.