Well I converted my single disk system last night into a dual disk RAID-1 setup and preserved all my data. I Thought I'd share an overview of the process and what I had problems with, maybe somebody here can use my experiences to help them.
First some background, I'm running Fedora 7 with all the current fedora patches, I am not using any third part repositories (yet) like Livna or Freshrpms.
The system is an Intel Pentium D processor with an Intel DG965RY motherboard utilizing 2- 400GB Seagate ST3400620AS SATA drives. NOTE: don't forget to remove the tiny jumper (and promptly loose it in carpet) on the drive to allow it to run at 3.0GB/s if your system allows it, the jumper comes installed by default limiting speed to 1.5Gb/s.
My system was running fine on /dev/sda, I added the new disk as /dev/sdb and partitioned it as follows:
/dev/sdb1 1 32 257008+ fd Linux raid autodetect /dev/sdb2 33 1307 10241437+ fd Linux raid autodetect /dev/sdb3 1308 1829 4192965 fd Linux raid autodetect /dev/sdb4 1830 48641 376017390 5 Extended /dev/sdb5 1830 2199 2971993+ fd Linux raid autodetect /dev/sdb6 2200 2568 2963961 fd Linux raid autodetect /dev/sdb7 2569 48641 370081341 fd Linux raid autodetect
My partitions were laid out as follows:
/dev/sdb1 = /dev/md1 = /boot /dev/sdb2 = /dev/md2 = /usr /dev/sdb3 = /dev/md3 = swap /dev/sdb4 = extended partition /dev/sdb5 = /dev/md5 = /var /dev/sdb6 = /dev/md6 = / /dev/sdb7 = /dev/md7 = /home
I kept the partition number the same as the raid partition number just because it made my life easier to keep track of everything but there is no reason it needs to match.
next I needed to create the partitions, this was pretty simple, I used the following command:
mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb1 missing mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb2 missing mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/sdb3 missing mdadm --create /dev/md5 --level=1 --raid-devices=2 /dev/sdb5 missing mdadm --create /dev/md6 --level=1 --raid-devices=2 /dev/sdb6 missing mdadm --create /dev/md7 --level=1 --raid-devices=2 /dev/sdb7 missing
Note the "missing" at the end of the command, this will allow the system to create the raid volumes since the other disk isn't available yet.
I created the file /etc/mdadm.conf and put the following in it. NOTE: if boot off a raid drive or load the raid module before mounting the partitions I don't think you need the "ARRAY" entries, but I used them anyway.
/etc/mdadm.conf: # Who should get alerts? MAILADDR root ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md2 devices=/dev/sda2,/dev/sdb2 ARRAY /dev/md3 devices=/dev/sda3,/dev/sdb3 ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md6 devices=/dev/sda6,/dev/sdb6 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7
NOTE: until the second disk was added to the array I only had one entry following the devices entry (eg devices=/dev/sdb1)
now you need to create the file systems, I kept everything as ext3 mkfs -V -t ext3 /dev/mdX
where X was 1, 2, 5, 6, & 7
Don't forget swap! mkswap /dev/md3
Now mount your new partitions, I mounted them under "/mnt"
mkdir /mnt/new-root mount /dev/md6 /mnt/new-root
create the new mount points (you could restore root first then just mount them) mkdir /mnt/new-root/var mkdir /mnt/new-root/usr mkdir /mnt/new-root/home mkdir /mnt/new-root/boot
mount /dev/md1 /mnt/new-root/boot mount /dev/md2 /mnt/new-root/usr
etc
Now comes the fun part, you need to move your data to the new partition. Although I've read where you can shrink the partition and convert to a raid volume, I decided against that.
I used dump/restore using the command:
dump -0 -b 1024 -f - /dev/sdaX | restore -rf -
NOTE: I'd recommend single user mode for the copy, better yet unmount the source volume if possible, secondly run this command in the destination directory!
Second NOTE: by using the option -b 1024 the performance of dump was increased about 10 fold however upon completion you will get "broken pipe" error, I found everything was copied properly and didn't worry about it.
All your data is copied to the RAID volume but a reboot will only load from the old disk. I did the following:
modified /etc/fstab to read:
/dev/md6 / ext3 defaults 1 1 /dev/md7 /home ext3 defaults 1 2 /dev/md5 /var ext3 defaults 1 2 /dev/md2 /usr ext3 defaults 1 2 /dev/md1 /boot ext3 defaults 1 2 /dev/md3 swap swap defaults 0 0
Note for clarity I removed tmpfs, devpts etc. Also in hindsight I probably could just use the label command "e2labe /dev/md1 /boot" etc but I wanted to be positive what would be mounted.
I modified grub.conf on *both* the new partition and the old partition to read:
kernel /vmlinuz-2.6.21-1.3228.fc7 ro root=/dev/md6
and then ran grub to install the boot loaded on the disks. grub-install /dev/sda grub-install /dev/sdb
At this point I rebooted.... and if your familiar with how raid works you'll know the system wouldn't boot. At this point I booted off the rescue disk and was able to mount all my raid partitions. Of course that didn't help me get the system reloaded so I started searching the internet for clues.
The answer came in mkinitrd mounted my partitions in the recovery mode, now knowing what I know now should have been prior to the first reboot.
rename the existing initrd file to something else ( eg .old ?) then from the new /boot directory run the following, and copy it to the old boot directory as well (unless you can boot from /dev/sdb in your bios)
mkinitrd --preload=raid1 initrd-2.6.21.1.3228.fc7.img 2.6.21.1.3228.fc7
At this point you should be able to reboot and the system will be running on the (degraded) RAID disks.
If your happy with everything then you can repartition your original drive (fdisk) to match /dev/sdb once that is done you need to add the new partitions to the raid volume. To do this enter the command:
mdadm --add /dev/mdX /dev/sdaX (where X is the partition number of the volume)
Do this for all your remaining partitions, and then you can cat /proc/mdstat and see the volumes being rebuilt ( hint: "watch cat /proc/mdstat")
Your done!
Hope this was helpful to somebody.
Jeff
Jeff, Thanks
Michael E. Ferguson
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Jeffrey Ross Sent: Saturday, June 30, 2007 2:03 PM To: For users of Fedora Subject: RAID gotchas!
Well I converted my single disk system last night into a dual disk RAID-1 setup and preserved all my data. I Thought I'd share an overview of the process and what I had problems with, maybe somebody here can use my experiences to help them.
First some background, I'm running Fedora 7 with all the current fedora patches, I am not using any third part repositories (yet) like Livna or Freshrpms.
The system is an Intel Pentium D processor with an Intel DG965RY motherboard utilizing 2- 400GB Seagate ST3400620AS SATA drives. NOTE: don't forget to remove the tiny jumper (and promptly loose it in carpet) on the drive to allow it to run at 3.0GB/s if your system allows it, the jumper comes installed by default limiting speed to 1.5Gb/s.
My system was running fine on /dev/sda, I added the new disk as /dev/sdb and partitioned it as follows:
/dev/sdb1 1 32 257008+ fd Linux raid autodetect /dev/sdb2 33 1307 10241437+ fd Linux raid autodetect /dev/sdb3 1308 1829 4192965 fd Linux raid autodetect /dev/sdb4 1830 48641 376017390 5 Extended /dev/sdb5 1830 2199 2971993+ fd Linux raid autodetect /dev/sdb6 2200 2568 2963961 fd Linux raid autodetect /dev/sdb7 2569 48641 370081341 fd Linux raid autodetect
My partitions were laid out as follows:
/dev/sdb1 = /dev/md1 = /boot /dev/sdb2 = /dev/md2 = /usr /dev/sdb3 = /dev/md3 = swap /dev/sdb4 = extended partition /dev/sdb5 = /dev/md5 = /var /dev/sdb6 = /dev/md6 = / /dev/sdb7 = /dev/md7 = /home
I kept the partition number the same as the raid partition number just because it made my life easier to keep track of everything but there is no reason it needs to match.
next I needed to create the partitions, this was pretty simple, I used the following command:
mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb1 missing mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb2 missing mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/sdb3 missing mdadm --create /dev/md5 --level=1 --raid-devices=2 /dev/sdb5 missing mdadm --create /dev/md6 --level=1 --raid-devices=2 /dev/sdb6 missing mdadm --create /dev/md7 --level=1 --raid-devices=2 /dev/sdb7 missing
Note the "missing" at the end of the command, this will allow the system to create the raid volumes since the other disk isn't available yet.
I created the file /etc/mdadm.conf and put the following in it. NOTE: if boot off a raid drive or load the raid module before mounting the partitions I don't think you need the "ARRAY" entries, but I used them anyway.
/etc/mdadm.conf: # Who should get alerts? MAILADDR root ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md2 devices=/dev/sda2,/dev/sdb2 ARRAY /dev/md3 devices=/dev/sda3,/dev/sdb3 ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5 ARRAY /dev/md6 devices=/dev/sda6,/dev/sdb6 ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7
NOTE: until the second disk was added to the array I only had one entry following the devices entry (eg devices=/dev/sdb1)
now you need to create the file systems, I kept everything as ext3 mkfs -V -t ext3 /dev/mdX
where X was 1, 2, 5, 6, & 7
Don't forget swap! mkswap /dev/md3
Now mount your new partitions, I mounted them under "/mnt"
mkdir /mnt/new-root mount /dev/md6 /mnt/new-root
create the new mount points (you could restore root first then just mount them) mkdir /mnt/new-root/var mkdir /mnt/new-root/usr mkdir /mnt/new-root/home mkdir /mnt/new-root/boot
mount /dev/md1 /mnt/new-root/boot mount /dev/md2 /mnt/new-root/usr
etc
Now comes the fun part, you need to move your data to the new partition. Although I've read where you can shrink the partition and convert to a raid volume, I decided against that.
I used dump/restore using the command:
dump -0 -b 1024 -f - /dev/sdaX | restore -rf -
NOTE: I'd recommend single user mode for the copy, better yet unmount the source volume if possible, secondly run this command in the destination directory!
Second NOTE: by using the option -b 1024 the performance of dump was increased about 10 fold however upon completion you will get "broken pipe" error, I found everything was copied properly and didn't worry about it.
All your data is copied to the RAID volume but a reboot will only load from the old disk. I did the following:
modified /etc/fstab to read:
/dev/md6 / ext3 defaults 1 1 /dev/md7 /home ext3 defaults 1 2 /dev/md5 /var ext3 defaults 1 2 /dev/md2 /usr ext3 defaults 1 2 /dev/md1 /boot ext3 defaults 1 2 /dev/md3 swap swap defaults 0 0
Note for clarity I removed tmpfs, devpts etc. Also in hindsight I probably could just use the label command "e2labe /dev/md1 /boot" etc but I wanted to be positive what would be mounted.
I modified grub.conf on *both* the new partition and the old partition to read:
kernel /vmlinuz-2.6.21-1.3228.fc7 ro root=/dev/md6
and then ran grub to install the boot loaded on the disks. grub-install /dev/sda grub-install /dev/sdb
At this point I rebooted.... and if your familiar with how raid works you'll know the system wouldn't boot. At this point I booted off the rescue disk and was able to mount all my raid partitions. Of course that didn't help me get the system reloaded so I started searching the internet for clues.
The answer came in mkinitrd mounted my partitions in the recovery mode, now knowing what I know now should have been prior to the first reboot.
rename the existing initrd file to something else ( eg .old ?) then from the new /boot directory run the following, and copy it to the old boot directory as well (unless you can boot from /dev/sdb in your bios)
mkinitrd --preload=raid1 initrd-2.6.21.1.3228.fc7.img 2.6.21.1.3228.fc7
At this point you should be able to reboot and the system will be running on the (degraded) RAID disks.
If your happy with everything then you can repartition your original drive (fdisk) to match /dev/sdb once that is done you need to add the new partitions to the raid volume. To do this enter the command:
mdadm --add /dev/mdX /dev/sdaX (where X is the partition number of the volume)
Do this for all your remaining partitions, and then you can cat /proc/mdstat and see the volumes being rebuilt ( hint: "watch cat /proc/mdstat")
Your done!
Hope this was helpful to somebody.
Jeff
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Jeffrey Ross wrote:
Now comes the fun part, you need to move your data to the new partition. Although I've read where you can shrink the partition and convert to a raid volume, I decided against that.
I used dump/restore using the command:
dump -0 -b 1024 -f - /dev/sdaX | restore -rf -
I've tried the shrink method in the past without problems (I think you have read my own description of the needed steps). In other cases, I just copied the files (you get a free defrag too). I'd trust cp, "tar c|tar x", rsync (all with powerful "copy everything" options), but I would be a little worried about dump/restore (in any case I usually work on reiserfs, so dump/restore is not an option).
Dump is considered a bad choice by Linus himself; read this:
http://lwn.net/2001/0503/a/lt-dump.php3
(a few years ago, but the words are quite strong)
Best regards.
Roberto Ragusa wrote:
Jeffrey Ross wrote:
Now comes the fun part, you need to move your data to the new partition. Although I've read where you can shrink the partition and convert to a raid volume, I decided against that.
I used dump/restore using the command:
dump -0 -b 1024 -f - /dev/sdaX | restore -rf -
I've tried the shrink method in the past without problems (I think you have read my own description of the needed steps). In other cases, I just copied the files (you get a free defrag too). I'd trust cp, "tar c|tar x", rsync (all with powerful "copy everything" options), but I would be a little worried about dump/restore (in any case I usually work on reiserfs, so dump/restore is not an option).
Dump is considered a bad choice by Linus himself; read this:
http://lwn.net/2001/0503/a/lt-dump.php3
(a few years ago, but the words are quite strong)
Best regards.
I've read the arguments here's the rebuttal to the 2001 message: http://dump.sourceforge.net/isdumpdeprecated.html
Jeffrey Ross wrote:
Roberto Ragusa wrote:
Dump is considered a bad choice by Linus himself; read this:
http://lwn.net/2001/0503/a/lt-dump.php3
(a few years ago, but the words are quite strong)
Best regards.
I've read the arguments here's the rebuttal to the 2001 message: http://dump.sourceforge.net/isdumpdeprecated.html
Thank you for this link, very interesting. Basically thay say that there was a bug in 2.4, now fixed.
They claim three advantages when using dump, but they are rather weak, I have to say (IMHO).
1) dump unmounted filesystem; but why not just mount it read-only and use a normal file copy tool? they talk about trying to dump corrupted unmountable filesystems for rescue purposes, but it looks like a very stretched motivation, especially when trying to prove that dump is preferable for normal uncorrupted filesystems.
2) dump doesn't modify the access time of the files on the filesystem; well, you can mount read-only or noatime.
3) dump is faster; no benchmark is available and they also doubt that this is valid today, given great filesystem caches.
They, honestly, list one disadvantage:
1) dump needs knowledge of filesystem internals, so no reiser or other kind of filesystem; normal file copy works on everything (including nfs)
But they forget to say that:
1) parsing the internals of the filesystem is a duplication of the filesystem code; as dump is certainly less tested than the actual filesystem code, I'd trust the latter for my backups.
2) accessing the device twice at the same time (filesystem+dump) is a recipe for inconsistency because of the filesystem cache; they suggest to sync the filesystem and keep low activity or, better, to unmount or mount read-only before running dump. They also acknowledge that this is a fundamental issue that cannot be fixed (paragraph "Is that problem peculiar to Linux?").
3) dump has to be costantly keep aligned to the filesystem improvements: many things where added to ext3 during its life (e.g. EA/ACL), and ext4 will be available in a few months.
4) it is true that backup of "live" data is a fundamentally undefined problem, but with file copy tools I'm definitively sure that working in a directory while copying another works well; with dump I'm not so sure.
5) file copy tools can descend in other filesystems (or not, as they often have the -x option).
6) dump can not create accessible backups; I want to be able to use the files in my backup (find, grep,...), not just restore them.
Finally they say that by using snapshots you can have a stable read-only image of the filesystem to run dump on. But the same is true for other tools too.
Certainly there is not a right way and wrong way to do things. If dump gives you reliable backups and you are used to it, it's a valid choice.
File copy tools will remain my preferred choice. In this exact moment I have two backups running across the LAN; they involve a couple of millions of files; one is using tar|tar, another rsync. (I'm not kidding) All filesystems are reiser here, so I couldn't try dump if I wanted, but even if I could, I think I would not. :-)
You gave me an opportunity to understand dump better. For what I've seen, it should be called e2dump and should be part of ext2progs, together with e2fsck, e2label, resize2fs and dumpe2fs (which is something else). It is a filesystem tool, not a file tool. Linux is not always ext2/ext3.
Maybe the summary of all this is just that dump is a tool to backup a filesystem, but I want to backup the files.
Best regards.
Roberto Ragusa wrote:
Jeffrey Ross wrote:
Roberto Ragusa wrote:
Dump is considered a bad choice by Linus himself; read this:
http://lwn.net/2001/0503/a/lt-dump.php3
(a few years ago, but the words are quite strong)
Best regards.
I've read the arguments here's the rebuttal to the 2001 message: http://dump.sourceforge.net/isdumpdeprecated.html
Thank you for this link, very interesting. Basically thay say that there was a bug in 2.4, now fixed.
They claim three advantages when using dump, but they are rather weak, I have to say (IMHO).
- dump unmounted filesystem; but why not just mount it read-only
and use a normal file copy tool? they talk about trying to dump corrupted unmountable filesystems for rescue purposes, but it looks like a very stretched motivation, especially when trying to prove that dump is preferable for normal uncorrupted filesystems.
For less informed readers (or curious readers later finding this thread in a search of the archives), copying unmountable file systems is already possible: use dd. You can even take the image of a partition (or a whole drive) and mount the file system located within it using loop devices (though the whole drive takes more work aligning the mount to the beginning of a "partition", and thus, an understandable file system).
[snip]
- dump can not create accessible backups; I want to be able
to use the files in my backup (find, grep,...), not just restore them.
Using the method I describe above, this is possible.
Finally they say that by using snapshots you can have a stable read-only image of the filesystem to run dump on. But the same is true for other tools too.
I just backed up my server using a combination of an LVM snapshot, dd to copy the partition initially, and now it'll be maintained with nightly rsyncs to a mounted image file. (Note: If anyone is interested, I can post some documentation describing how I set up the backup and the script which will keep my backup up-to-date).
Certainly there is not a right way and wrong way to do things. If dump gives you reliable backups and you are used to it, it's a valid choice.
File copy tools will remain my preferred choice. In this exact moment I have two backups running across the LAN; they involve a couple of millions of files; one is using tar|tar, another rsync. (I'm not kidding) All filesystems are reiser here, so I couldn't try dump if I wanted, but even if I could, I think I would not. :-)
You gave me an opportunity to understand dump better. For what I've seen, it should be called e2dump and should be part of ext2progs, together with e2fsck, e2label, resize2fs and dumpe2fs (which is something else). It is a filesystem tool, not a file tool. Linux is not always ext2/ext3.
Maybe the summary of all this is just that dump is a tool to backup a filesystem, but I want to backup the files.
Best regards.
Justin W
Justin, Thanks for the offer. Please post, or send me the documentation on how to.
'preciate it.
Ferg'
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Justin W Sent: Monday, July 02, 2007 9:03 PM To: For users of Fedora Subject: Re: RAID gotchas!
Roberto Ragusa wrote:
Jeffrey Ross wrote:
Roberto Ragusa wrote:
Dump is considered a bad choice by Linus himself; read this:
http://lwn.net/2001/0503/a/lt-dump.php3
(a few years ago, but the words are quite strong)
Best regards.
I've read the arguments here's the rebuttal to the 2001 message: http://dump.sourceforge.net/isdumpdeprecated.html
Thank you for this link, very interesting. Basically thay say that there was a bug in 2.4, now fixed.
They claim three advantages when using dump, but they are rather weak, I have to say (IMHO).
- dump unmounted filesystem; but why not just mount it read-only and
use a normal file copy tool? they talk about trying to dump corrupted unmountable filesystems for rescue purposes, but it looks like a very stretched motivation, especially when trying to prove that dump is preferable for normal uncorrupted filesystems.
For less informed readers (or curious readers later finding this thread in a search of the archives), copying unmountable file systems is already possible: use dd. You can even take the image of a partition (or a whole drive) and mount the file system located within it using loop devices (though the whole drive takes more work aligning the mount to the beginning of a "partition", and thus, an understandable file system).
[snip]
- dump can not create accessible backups; I want to be able to use
the files in my backup (find, grep,...), not just restore them.
Using the method I describe above, this is possible.
Finally they say that by using snapshots you can have a stable read-only image of the filesystem to run dump on. But the same is true for other tools too.
I just backed up my server using a combination of an LVM snapshot, dd to copy the partition initially, and now it'll be maintained with nightly rsyncs to a mounted image file. (Note: If anyone is interested, I can post some documentation describing how I set up the backup and the script which will keep my backup up-to-date).
Certainly there is not a right way and wrong way to do things. If dump gives you reliable backups and you are used to it, it's a valid choice.
File copy tools will remain my preferred choice. In this exact moment I have two backups running across the LAN; they involve a couple of millions of files; one is using tar|tar, another rsync. (I'm not kidding) All filesystems are reiser here, so I couldn't try dump if I wanted, but even if I could, I think I would not. :-)
You gave me an opportunity to understand dump better. For what I've seen, it should be called e2dump and should be part of ext2progs, together with e2fsck, e2label, resize2fs and dumpe2fs (which is something else). It is a filesystem tool, not a file tool. Linux is not always ext2/ext3.
Maybe the summary of all this is just that dump is a tool to backup a filesystem, but I want to backup the files.
Best regards.
Justin W
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Ferguson, Michael wrote:
Justin W wrote:
I just backed up my server using a combination of an LVM snapshot, dd to copy the partition initially, and now it'll be maintained with nightly rsyncs to a mounted image file. (Note: If anyone is interested, I can post some documentation describing how I set up the backup and the script which will keep my backup up-to-date).
Justin, Thanks for the offer. Please post, or send me the documentation on how to.
'preciate it.
Ferg'
I'm currently in the process of rewriting the script and such so that there is not so much manual input. If I succeed, the script should be quite portable across similar setups, but for now, you're going to have to change many of the path names to how they apply to you.
The documentation is in the file backup.html which I've attached, and then the script which accompanies it is in the file backup-slash-fs.
If I get the new version completed in a reasonable amount of time, I'll repost that one too, but I'm not making any promises.
Justin W
#!/bin/bash
# Overview of backup process # 1) Create a FS snapshot using LVM # 2) Mount the snapshot FS # 3) Mount our backup file in a loop filesystem (we can guarantee the space # will be present this way, and it allows selective recovery of files if # need be) # 4) rsync the differences between the snapshot FS and the backup FS # 5) Unmount the backup FS # 6) Unmount the snapshot FS # 7) Delete the snapshot LVM (leaving it will degrade performance)
# Create the LVM snapshot lvcreate -s -L40G -n FC6Backup /dev/System/fc6
# Mount our filesystems mount /dev/System/FC6Backup /mnt/FC6-Snapshot mount -o loop /mnt/smb/userdata/root/FC6-Backup-File /mnt/FC6-Backup
# Update the backup file system with files from the snapshot rsync -aHEAXxv --stats --delete --ignore-errors /mnt/FC6-Snapshot/* /mnt/FC6-Backup
# Unmount the backups umount /mnt/FC6-Backup umount /mnt/FC6-Snapshot
# Delete the snapshot lvremove -f /dev/System/FC6Backup
# Create a link to the backup file which (in the name) indicates the date of # the backup cd /mnt/smb/userdata/root rm -f FC6-Backup_* ln -s FC6-Backup-File FC6-Backup_$(date +%F)
Thanks
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Justin W Sent: Tuesday, July 03, 2007 10:56 AM To: For users of Fedora Subject: Re: RAID gotchas!
Ferguson, Michael wrote:
Justin W wrote:
I just backed up my server using a combination of an LVM snapshot, dd to copy the partition initially, and now it'll be maintained with nightly rsyncs to a mounted image file. (Note: If anyone is interested, I can post some documentation describing how I set up the backup and the script which will keep my backup up-to-date).
Justin, Thanks for the offer. Please post, or send me the documentation on how to.
'preciate it.
Ferg'
I'm currently in the process of rewriting the script and such so that there is not so much manual input. If I succeed, the script should be quite portable across similar setups, but for now, you're going to have to change many of the path names to how they apply to you.
The documentation is in the file backup.html which I've attached, and then the script which accompanies it is in the file backup-slash-fs.
If I get the new version completed in a reasonable amount of time, I'll repost that one too, but I'm not making any promises.
Justin W
Justin W wrote:
I'm currently in the process of rewriting the script and such so that there is not so much manual input. If I succeed, the script should be quite portable across similar setups, but for now, you're going to have to change many of the path names to how they apply to you.
Your approach is interesting, because (in likely conditions) you use the fastest method to create the first copy (dd) and the fastest method to update the backup (rsync). Then, you keep two options for restoration: total fileystem (dd) and selective file copy.
The only tricky part I see is what happens when you enlarge your filesystem (which I suppose you sometimes do, as you use LVM).
You have to recreate the image with dd; otherwise you have to manually extend the image file and the filesystem contained in it. This is possible but you have to calculate the new size very accurately; you managed to avoid that when creating the first copy as dd handled the end of partition for you. It could be automated with something like lvs -o lv_size --units=b --nosuffix --noheadings vgname/lvname
Thinking about it, the extension of the file image can be done very quickly using dd seek=xxx (obtaining a sparse file).
Best regards.
Roberto Ragusa wrote:
Justin W wrote:
I'm currently in the process of rewriting the script and such so that there is not so much manual input. If I succeed, the script should be quite portable across similar setups, but for now, you're going to have to change many of the path names to how they apply to you.
Your approach is interesting, because (in likely conditions) you use the fastest method to create the first copy (dd) and the fastest method to update the backup (rsync). Then, you keep two options for restoration: total fileystem (dd) and selective file copy.
Thanks for the encouragement. I've been running a server for close to 4 years now, but this is the first week I've had a solid backup of the system. Though one major reason until now was the lack of necessary hardware, the logistics of how to backup my server without taking it down into single user mode had eluded me. The solution had finally come once I heard some mention of LVM snapshots and read more up on them. A priority of mine was to be able to selectively search through files (in the case when I completely reinstall my server and just want to copy configuration), but I also needed quick recovery just in case my hard drive dies unexpectedly and a quick come back is needed (where I restore an entire image).
The only tricky part I see is what happens when you enlarge your filesystem (which I suppose you sometimes do, as you use LVM).
You have to recreate the image with dd; otherwise you have to manually extend the image file and the filesystem contained in it. This is possible but you have to calculate the new size very accurately; you managed to avoid that when creating the first copy as dd handled the end of partition for you. It could be automated with something like lvs -o lv_size --units=b --nosuffix --noheadings vgname/lvname
Thinking about it, the extension of the file image can be done very quickly using dd seek=xxx (obtaining a sparse file).
I never really considered what would happen if I expanded the partition. If I'm going through the trouble of doing that, I don't really see a problem with recreating the backup image all over again. It's a really simple process, and most of the time is just spent waiting for it to complete. If I read more on dd, I'm sure there are ways to optimize the buffer sizes and such which could speed up the copy, but as it wasn't a big deal to me, I didn't really bother.
Best regards.
Suggestions as to how I can improve the efficiency of the dd copy or better flags for rsync are welcome.
Justin W
Justin W wrote:
Ferguson, Michael wrote:
Justin W wrote:
I just backed up my server using a combination of an LVM snapshot, dd to copy the partition initially, and now it'll be maintained with nightly rsyncs to a mounted image file. (Note: If anyone is interested, I can post some documentation describing how I set up the backup and the script which will keep my backup up-to-date).
Justin, Thanks for the offer. Please post, or send me the documentation on how to.
'preciate it. Ferg'
I'm currently in the process of rewriting the script and such so that there is not so much manual input. If I succeed, the script should be quite portable across similar setups, but for now, you're going to have to change many of the path names to how they apply to you.
I've completed the update. This should be much more portable, and convenient. The last upgrade I can see is making a small script to do the initial image creation, but I don't think I'm going to be doing that any time soon (too many other projects to get started on right now).
Enjoy!
Justin W
#!/bin/bash
# Overview of backup process # 1) Read and parse configuration file # 2) Loop through each backup # 3) Create a FS snapshot using LVM # 4) Mount the snapshot FS # 5) Mount our backup file in a loop filesystem (we can guarantee the space # will be present this way, and it allows selective recovery of files if # need be) # 6) rsync the differences between the snapshot FS and the backup FS # 7) Unmount the backup FS # 8) Unmount the snapshot FS # 9) Delete the snapshot LVM (leaving it will degrade performance) # 10) Repeat 3-9 if necessary
# Save the old IFS variable so that we can restore it when we're done ORIGIFS=$IFS IFS=$(echo -en "\n\b")
# User where the reports of the backup are sent to MAILTO=root
# Read from the configuration file any exclude filters for the rsync output LOG_EXCLUDE=$(cat "$PWD/backup.conf" | egrep "^[ \t]*LOG_EXCLUDE=" | cut -d'=' -f 2-) LOG_FILE=/tmp/backup$$.log
# Get each line from the configuration file one at a time, ignoring anything # that starts with a pound (#) sign for i in $(cat "$PWD/backup.conf" | egrep -v "^[ \t]*#.*|^[ \t]*LOG_EXCLUDE=.*"); do # Parse out the locations we need VOL=$(echo $i | sed "s@^([^:]*):(.*)@\1@") TARG=$(echo $i | sed "s@^([^:]*):(.*)@\2@")
# Check to make sure the paths are valid [ -b $VOL ] || { echo "Source volume not valid: $VOL. Skipping"; continue; } [ -f $TARG ] || { echo "Target image not valid: $TARG. Skipping"; continue; }
# Get necessary information about the source volume. # Get only the necessary line, and not the headers, and then compress the # info so it is only separated by a single space (makes finding fields # easier in the next steps). There will be an extra space at the beginning, # so fields are 1 greater than what they seem. # # Make sure the volume is a LVM Logical Volume lvs -a $VOL 2>/dev/null 1>/dev/null || { echo "$VOL not an LVM Logical Volume ($?). Skipping."; continue; } # Now we actually collect the info INFO=$(lvs -a $VOL | tail -n 1 | sed 's/[ ][ ]*/ /g') # Field 1: Logical Volume Name VOL_NAME=$(echo $INFO | cut -d' ' -f 2) # Field 2: Volume Group Name GROUP_NAME=$(echo $INFO | cut -d' ' -f 3) # Field 3: Attributes - Not needed right now, but may come in handy ATTRS=$(echo $INFO | cut -d' ' -f 4) # Field 4: Volume Size VOL_SIZE=$(echo $INFO | cut -d' ' -f 5)
# Now we just create a name for the snapshot volume, and then we can # create it SNAP_NAME=${VOL_NAME}$$ SNAP_PATH=/dev/${GROUP_NAME}/${SNAP_NAME} lvcreate -s -L${VOL_SIZE} -n $SNAP_NAME $VOL >/dev/null || { echo "Snapshot of '${GROUP_NAME}/${SNAP_NAME}' failed ($?). Skipping."; continue; } # Mount our filesystems at temporary mount locations SNAP_MOUNT=/tmp/backup-$SNAP_NAME TARG_MOUNT=/tmp/backup-target$$ mkdir $SNAP_MOUNT || { echo "Failed to create snapshot mount point ($?). Skipping."; cleanup; continue; } mkdir $TARG_MOUNT || { echo "Failed to create target mount point ($?). Skipping."; cleanup; continue; } mount $SNAP_PATH $SNAP_MOUNT || { echo "Mounting snapshot failed ($?). Skipping."; cleanup; continue; } mount -o loop $TARG $TARG_MOUNT || { echo "Mounting target image failed ($?). Skipping."; cleanup; continue; }
# Update the backup file system with files from the snapshot # IMPORTANT!!: The trailing slash on the source is necessary for it to # work in the expected way, or else all backups will end up within a # subdirectory with the name $SNAP_MOUNT rsync -aHEAXxv --stats --delete --ignore-errors $SNAP_MOUNT/ $TARG_MOUNT | \ egrep -v "$LOG_EXCLUDE" >> $LOG_FILE
# Cleanup stuff is put into a function so that it can be called before # an exit call function cleanup() { # Unmount the backups and remove the temporary dirs # Errors may occur here, but we don't really care. Just pipe the errors # to /dev/null umount $SNAP_MOUNT 2>/dev/null 1>/dev/null umount $TARG_MOUNT 2>/dev/null 1>/dev/null [ -d $SNAP_MOUNT ] && rmdir $SNAP_MOUNT [ -d $TARG_MOUNT ] && rmdir $TARG_MOUNT
# Delete the snapshot [ -b $SNAP_PATH ] && lvremove -f $SNAP_PATH >/dev/null } # Now call our cleanup routine on normal completions cleanup done
# Mail the log file, and then delete the file mail -s "Backups on $(hostname)" $MAILTO < $LOG_FILE rm $LOG_FILE
# Restore the IFS IFS=$ORIGIFS
# Any files which you don't want to show up in the rsync output (e.g. mail # spool files which change often, /tmp, etc.), can be filtered out using # `egrep' compatible regular expressions within a LOG_EXCLUDE variable. # Logged locations do not begin with the leading slash, so /tmp would be # filtered with an expression looking for "tmp/". # # Note: # the LOG_EXCLUDE line must follow bash variable requirements, so no space is # allowed before the equals sign. # # Example # LOG_EXCLUDE="tmp/|var/spool/mail" LOG_EXCLUDE="tmp/|var/spool|home/|var/log|var/cache"
# Configuring the script to back up a file system is a very simple process. # Most of the logic is calculated automatically, so only the original [LVM] # file system and the target image must be specified # # Example: # /dev/VolGroup00/LogVol00:/mnt/bigdrive/SysBackup # # This would create a backup of the LogVol00 LVM partition (which most of the # time happens to be the / file system, and it'll save it to the image SysBackup # which resides on an external hard drive.
/dev/System/fc6:/mnt/smb/userdata/root/FC6-Backup-File
At 2:16 PM +0200 7/2/07, Roberto Ragusa wrote: ...
Dump is considered a bad choice by Linus himself; read this:
http://lwn.net/2001/0503/a/lt-dump.php3
(a few years ago, but the words are quite strong)
Linus can be wrong. See http://dump.sourceforge.net/isdumpdeprecated.html . In short, no program can safely back up a live filesystem, so don't claim that dump has a problem when all backup programs also have the problem. If the OP used dump on an unmounted filesystem as he himself recommends, Linus' comments would not apply at all, nor would they apply if an LVM Snapshot were used.
I use dump and cpio, but I do dump from unmounted filesystems and cpio from read-only filesystems. I have a DVD drive and I know how to boot from it.
-
Ferguson, Michael -
Jeffrey Ross -
Justin Willmert -
Roberto Ragusa -
Tony Nelson