LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 06-11-2010, 03:57 AM   #1
integrale16
Member
 
Registered: Sep 2009
Posts: 56

Rep: Reputation: 15
filesystem errors after backup with dd


Hi,

in preparation for the update to Slackware64 13.1 I did a complete backup of my system with dd.

I used the Slackware 13.0 (not 64 bit) DVD to boot and executed the command:
# dd if=/dev/sda of=/dev/sdb

The command finished without any errors as expected.
First I tried to boot the destination hard disk to check if the backup was successful and I can start with updating the source disk to 13.1. But at boot time I got the message that the last file system check is 197 day ago, the file system check started automatically and found errors which it could not correct. At this point I thought it was maybe a copy or a hard disk error and tried to boot the source disk.
But the behaviour was exactly the same on the source disk. With the source disk I followed then the recommendation, logged in with root password and executed the recommended command which was something like e2fsck -v -h /dev/sda1. Then the system did a file system check and scrolled a lot of numbers over the screen. After a while it reported that it's ready and the system needs a restart.
I switched off and on again. Then the system bootet as usual, and seems to run okay at the moment. But now I'm unsure if really everything is okay.

What I'm confused of is, why the system reported that the last file system check was 197 days ago and why this was just after the dd backup. Shouldn't the automatic file system check at boot time run more often as every 197 days or mounts? I didn't change any default settings (as far as I know). The file system of the root partition is ext4 and my computer normally is switched on and off once every day.

My question now is, if this behaviour can have something to do with the dd backup.
Is my system after the file system check okay again, or should I expect further problems?
Every explanations and suggestions are welcome.
Thanks.


integrale16
 
Old 06-11-2010, 06:18 AM   #2
halvy
Member
 
Registered: Aug 2005
Location: Boston Massachussets, USA
Distribution: Anything NOT SystemD (ie. M$) related.
Posts: 917

Rep: Reputation: 41
Thumbs up

I stay away from dd unless it is absolutely necessary (which is never)... there are just tooo many other, better, faster, safer, alternatives (dump, tar, rsync, etc..).

You did not mention if the new device was booting (sdb?).

Your original system should be ok.. but as usual, you can NEVER make enough back-ups of your work.

Especially with ext4.. which I did quite a lot of research, and trial and error, before I was ok with it.

I would not worry about your main system now.. just keep an eye on it for a few daze..

I run ext4 full blast .. no barriers, no journel.. etc.. to get the most of it's new speed advantages.. (esp. with fsck and copying large files..).

Anyway, lettuce know
 
0 members found this post helpful.
Old 06-11-2010, 08:13 AM   #3
sparkyhall
Member
 
Registered: Nov 2009
Location: Chatteris---UK
Distribution: Slackware 13.0 & 14.0
Posts: 41

Rep: Reputation: 7
Did you remember to modify /etc/fstab before booting /dev/sdb. If not then fstab will still be pointing to /dev/sdax for your root file system, which may explain how your original file system became corrupt.
 
Old 06-11-2010, 08:43 AM   #4
integrale16
Member
 
Registered: Sep 2009
Posts: 56

Original Poster
Rep: Reputation: 15
When I bootet the backup disk (sdb) to check if it's working, it was not recognized as /dev/sdb but /dev/sda because I unplugged the source disk before booting the backup disk.
So it should not be necessary to modify /etc/fstab.

This is also the reason why I did the backup with dd, because then I (should) have a backup that I only have to plug instead of the original disk and have a working system without restoring something, or so.
 
Old 06-11-2010, 12:16 PM   #5
integrale16
Member
 
Registered: Sep 2009
Posts: 56

Original Poster
Rep: Reputation: 15
What I don't understand is:

Why did my system work without any problems before, when there were thousands of filesystem inconsistencies?

Or did the file system inconsistencies come from the dd (which I can't imagine) and everything was okay before the backup.

So far my system is still working (I'm writing this email on it) without any trouble after the file system check.

Next step will be to have a look, if the backup disk also works after the recommended e2fsck command.
 
Old 06-11-2010, 12:35 PM   #6
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
I wouldn't blame dd for this, I've never heard of it corrupting data, especially when it is reading from that data. The cause must be something else. Are you sure the drive you copied from is ok, check with 'smartctl -A' and maybe a long test.
 
Old 06-11-2010, 01:11 PM   #7
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 223Reputation: 223Reputation: 223
There's only a few reasons one should use dd to backup/clone a hard drive. Other tools are not available, other tools don't support the file system, you're making an image for forensics and need an exact bit to bit copy.

Some gotcha's for dd. When you dd dev/sda to dev/sdb this copies everything not just the data, but geometry, partition layout, everything. Unless the disks are identical, it's not a wise thing to do. It's better to dd specific partitions. Not only that, but dd copies sector to sector regardless if it is occupied with data or not.

cp and/or tar will work just fine. I based my method off the following link -> https://help.ubuntu.com/community/BackupYourSystem/TAR

Clonezilla is a live cd that makes it simple to accomplish this.
 
Old 06-11-2010, 03:40 PM   #8
halvy
Member
 
Registered: Aug 2005
Location: Boston Massachussets, USA
Distribution: Anything NOT SystemD (ie. M$) related.
Posts: 917

Rep: Reputation: 41
Tex.. no disrespect.. but you never heard of dd causing data corruptions.. lol

And 'Disturbed'..uh.. dd is only one tool one would use in forensics.. BECAUSE.. it actually does NOT copy the whole drive.. even tho it does in fact copy the items that you listed.

There ARE areas that are hidden..even to dd.. and most forensics specialists..

Some of these areas are known, partially, as the 'Hidden Partition Area' (HPA) and 'Device Configuration Overlay (DCO).

These areas, if you are interested in more research, are sometimes legitimate, and sometimes not.

However be forewarned, there is scant, inclusive, and questionable data available on the Net about these mysterious areas of forensics.

OP originally stated he used the command: dd if=/dev/sda of=/dev/sdb ....

Well I'm not sure what type of result that would (should) give.. because it seems there were some important switches left off of the command.

This obviously could be part of the reason for the phantom type errors and results that OP got.
 
0 members found this post helpful.
Old 06-11-2010, 04:06 PM   #9
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
dd can corrupt data, but it's your fault if it does, so it's not dd's fault

It's true dd is not the best way to backup data. Imagine if the drive failed as you are backing up.
 
Old 06-13-2010, 10:06 AM   #10
integrale16
Member
 
Registered: Sep 2009
Posts: 56

Original Poster
Rep: Reputation: 15
Thanks for your answers.

The two drives have exactly the same size and the behaviour of the two disks after the dd backup was exactly the same. With both drives I got the message the the last file system check was 197 days ago and finally I could (hopefully) get rid of the file system errors with the recommended command "e2fsck -v -y /dev/sda1".

If only the destination drive would have shown a weird behaviour, then I would have thought it was an error in the backup process. But what I found strange was, that both drives had the same behaviour.

What is the default setting for the interval of a file system check on ext4?
If it's something between 200 and 300 boots then maybe it was just an accident that the file system check had to happen exactly after the backup and the errors were already present before and were also copied to the destination disk.

At the end it seems that both disk are working again after the file system check and could do my update to 13.1.
 
Old 06-13-2010, 11:57 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,564
Blog Entries: 54

Rep: Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927Reputation: 2927
Quote:
Originally Posted by halvy View Post
There ARE areas that are hidden..even to dd.. and most forensics specialists.. Some of these areas are known, partially, as the 'Hidden Partition Area' (HPA) and 'Device Configuration Overlay (DCO). These areas, if you are interested in more research, are sometimes legitimate, and sometimes not. However be forewarned, there is scant, inclusive, and questionable data available on the Net about these mysterious areas of forensics.
There is nothing mysterious about HPA. And the state of documentation definitely is not "scant" or "questionable". The Linux kernel will tell you on boot if it detects a HPA ('dmesg|grep HPA'), the libata LKM has a compatibility switch ('modinfo libata|grep ignore_hpa') and userland tools are available to detect ('hdparm', 'disk_stat') and reset ('setmax', 'disk_sreset') a HPA.


Quote:
Originally Posted by halvy View Post
This obviously could be part of the reason for the phantom type errors and results that OP got.
'dd' makes a bit-level copy of the drive. The OP experienced FS-level problems. Completely different layer, completely different type of problem.
 
Old 06-13-2010, 04:01 PM   #12
vehn
Member
 
Registered: Dec 2007
Posts: 54

Rep: Reputation: 17
H_TeXMeX_H is right. You need immediately backup sensitive data and test your hard drive with smartmontools (http://slackbuilds.org/repository/13...gsmartcontrol/ -- GUI to smartmontools).

Why you had problem after running dd? First, in your case, you do not correctly used the command dd. You need use option 'bs' in such cases (see man dd). By default dd copies per small block (in your case, without options), it is very heavy for disk subsystem when copying large amounts of data. In fact, you tested your hard drive for durability. The test was not passed. The reasons may be several. In my case, in similar circumstances, it was the temperature above 50 degrees Celsius. In your case, when there was copying, has failed and the disk subsystem mark bad sector(s) as unreadable, respectively a small piece of information was lost, respectively copied file system came in inconsistent state, hence the errors at startup. As for the time: check the system time in BIOS, it lags behind the real on 197 days.

If you have no idea about S.M.A.R.T., to quickly check if everything is in order, you can download the latest livecd Fedora. Boot from it and wait 2-5 minutes. If there are problems in the notification area will notice, if not, read smartmontools's docs (a lot of useful information on their site).

I hope I'm wrong.
Sorry for bad English.

Last edited by vehn; 06-13-2010 at 04:04 PM.
 
Old 06-15-2010, 03:15 PM   #13
integrale16
Member
 
Registered: Sep 2009
Posts: 56

Original Poster
Rep: Reputation: 15
The short test with gsmartcontrol was ok.
The extended test I will do another day, I don't have two hours time now.
Sensitive data is backed up also on another disk (only data without the system).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
backup RHEL 5 filesystem rawand Linux - Server 7 02-18-2010 07:57 AM
Filesystem errors linuxmandrake Linux - Newbie 12 02-02-2008 07:56 PM
linux filesystem backup tedious46 General 3 07-08-2006 05:38 PM
filesystem backup to DVD auditude Linux - Software 3 12-18-2004 08:15 AM
filesystem image backup to CD malbery Debian 2 09-30-2004 08:07 AM


All times are GMT -5. The time now is 01:34 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration