dd vs. partimage vs. tar?
Please don't flame! I did a search about backup techniques but it seems like I have to mix pieces of them to achieve what I want and that's whay I'm posting this. My problem would be: when I installed Linux (as a total n00b), I did it on a 2nd, 10 GB HD like this: / on /dev/hdb1, /home on /dev/hdb6 and swap on /dev/hdb5.
df shows: Code:
Filesystem Size Used Avail Use% Mounted on Then, on my first HD (120 GB), which holds XP(one partition), multimedia stuff, docs, etc. (2nd partition) I made with PMagic (from XP) a third partition (fat32, 6 GB) to backup hdb1. Then I did a dd if=/dev/hdb1 of=/dev/hda5 (under Knoppix, of course). Yet, a df shows the newly created and diskdumped hda5 to be exactly the size of hdb1 (2.6G) instead of 6G. Then I read that you need to use resize2fs to set the things up. The actual question(s) are: 1.how safe is it a resizing of hdb1 (and hdb6 accordingly) using qtparted from Knoppix? 2.if something goes wrong with the resizing (data loss on hdb1), is the following procedure right: -dd if=/dev/hda5 of=/dev/hdb1 -e2fsck -f /dev/hdb1 -resize2fs -f /dev/hdb1 3.(probably this one should have come first): why qtparted (from Knoppix) isn't allowing me to resize (greyed out buttons) hdb's partitions (even if I 'swapoff /dev/hdb5')? 4.'fdisk -l /dev/hdb' says: Code:
Disk /dev/hdb: 10.0 GB, 10005037056 bytes 5. would tar (or dar) be more suitable for what am I trying to do? That's about it...unless I come upon something else. Thanks to anyone who'll reply. |
Caveat; I have *NEVER* used any resizing tool. I'll buy a new disk in preference, and copy to that.
Rule no 1 -> infinity. - you can never have too many backups. If you only ever need to restore a "point-in-time" image, a block mode backup might be the way to go. Partimage and dd fall into this classification. In most cases not much use unless recovering back to the same disk (or same geometry). I like tar, and since I found it, dar even better - although I have yet to try the latter. Excellent solution though IMHO. Don't worry about the extended partition - they always show up like that |
Why don't you try this backup script package:
http://themlg.net/~offroad/tmp/backupscripts.tar.gz It has a README inside ... and you should be able to understand how it works ... GL |
Thanks for the link sys7em, but the archive doesn't contain any README file. Yet, I swepped over the shell script and it looks like it is designed to split data into 650 MB chunks and write them to a CD. Which is not what I am after.
Basically, I want to enlarge a partition using space from another one and I want to make sure I'm safe if something goes wrong. Other suggestions? |
Ok, let me put it another way: if, hypothetically, I want to wipe out the partition containing '/', an archive of it created with tar (dar) would allow me to restore it just as it was...and would it boot again like nothing happend? Even if I resize that partition?
Sorry for asking twice, but I thought I made my question a bit more "readable". |
Quote:
hdb6 is the second extended partition on the extended partion defined by hdb2. It is not contiguous with hdb1 (does not share a boundary with it) and is of a different type (extended partition vs primary partition). You cannot take space from hdb6 and add it to hdb1. The easiest thing for you to do would be to move your / to hdb6 and size it to suit yourself. You could make this change using dd then change your boot loader to deal with the new location. If you insist on keeping hdb1 as your root partition, then you need to do the following, in order. 1. back up the contents of hdb6. 2. disable swap. 3. delete hdb2 (which will delete hdb5 and hdb6 as well). 4. resize hdb1 to suit yourself, then resize the file system on hdb1. 5. recreate hdb2 beginning at the end of hdb1 and filling the rest of the disk. 6. recreate your swap as hdb5. 7. reenable swap 8. recreate hdb6 9. reload hdb6 from backup. |
Thanks, you made me open my eyes. It totally slipped my mind that hdb1 is primary while hdb6 is extended :(
Ok, I mainly get the idea but can you elaborate just a bit on points 4-6, 8? In fact, if I got it right, the corresponding steps would be: 1.tar(dar) hdb6 2.swapoff /dev/hdb5 3.fdisk (or qtparted) ->delete hdb2 4.-6.qtparted (+ fdisk maybe?) 7.swapon hdb5 8.qtparted again 9.i'll figure it out Please correct me where I'm wrong. And something else: if I do it like you said, I shouldn't worry about data loss on hdb1 because its end section will be altered, not the section that holds the actual data, right? Maybe you'd be so kind to recommend a adequate technique for point (1)? Thank you very much! |
you could resize the partition using parted or using sfdisk (if you know exactly what you are doing). I think you will have to resize the partition working from an alternate linux and not within your existing linux environment. If you are fearless you could use, for instance, lde to manually change the endpoint information in the partition table while up and running in Linux but if you make a mistake you could be very sorry. FWIW, this is how I would do it (using lde and manually changing the partition table on the fly with it). I then would boot into an alternate linux installation in order to use resize2fs to change the size of the file system to match the partition.
You can create partitions with any number of tools, including parted, fdisk, cfdisk, sfdisk, any of the distro graphical tools for disk management, etc. Actually, the easiest way to do all of this is to obtain a Knoppix CD and boot from that. There are graphical tools on Knoppix that will let you easily do the whole thing, including the delete and the nondestructive resize. |
Actually I do have a Knoppix 3.7 CD and the steps I mentioned were intended to be executed from Knoppix.
So, this being the situation, would it be right to proceed as I said? Some hints, advices? |
After reading some more Q&As on this topic here at LQ, I saw someone recommending the following procedure for resizing(enlarging) a partition: back it up with partimage, delete, recreate, (these 2 points with qtparted) restore the image then resize with resize2fs and everything should be ok.
Is it possible? In partimage's docs says that the partition on which the restoration will be made must be the same size as the old one. So? |
So ???.
The resizing is post the restore. Apparently works for o.k. ext2 - *not* ext3 I believe. I have to ask, why the hand-wringing and complexity ???. Backup the data on a filesystem basis (tar, dar, cpio whatever the hell that does the job). Delete the partitions, re-create them the required size, and restore the data. What's so damned hard ???. Sorry - it's late here, obviously time I went to bed. |
Quote:
Quote:
Quote:
Quote:
Quote:
I read today around 40 more threads resembling somewhat to this. Also around 20 yesterday. None of them describes exactly what I want to do. If my English isn't understandable, please let me know. I thought I asked (twice I might add) clearly which would be the best tool to backup data considering that it's going to be restored on a new, resized partition. Also, which is the best way to prevent data loss. Quote:
Quote:
Maybe this time someone will get what I'm asking and maybe I won't get only halves of answers. |
Quote:
You are just nervous. |
Yeah, you're probably right. Actually you ARE right. I'm sorry and I appologize for that...I was kind of tired (at 11 PM) reading so many posts with all kind of answers, none fitting me.
Anyway, I made it through using dar...it's a great tool and I warmly recommend it. |
All times are GMT -5. The time now is 10:35 AM. |