I've been working with a user on adding MBR backup options to the G4L, and have done so on the network menu. I've combined the B: and C: into just B:. Normally, it already gets the IP via DHCP, but if one now leaves the IP address BLANK, it will redo the dhcp. Did this to keep all options on Screen.
ftp://202.128.73.28/g4l-v0.30alpha32.iso
(includes kernel 2.6.29.1 and syslinux 3.74 pre 17)
This has the updated script with the new M: Option, but it only backs up the MBR and Physical partition table that is contained in the first 512 bytes of the disk. It Does not backup the logical partitions that are stored in EBRs on the disk at various locations. So, if you have only physical partitions this should work, but any logical partitions will not be included, so in that case you must do a full disk backup or manually create the partitions.
Now as for an update on the solutions that I am working on to fix this...
On my systems, I have the following partitions as reported by fdisk.
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xae34ae34
Device Boot Start End Blocks Id System
/dev/sda1 * 1 2433 19543041 c W95 FAT32 (LBA)
/dev/sda2 2434 9726 58581022+ f W95 Ext'd (LBA)
/dev/sda5 2434 4862 19510911 7 HPFS/NTFS
/dev/sda6 4863 4887 200781 83 Linux
/dev/sda7 4888 9726 38869236 8e Linux LVM
As you can see there are 3 logical partitions. The physical partitions would be included in the first 512 bytes, but not the 3 Logical partitions.
fdisk -lu /dev/sda shows the absolute sector numbers of the disk layout.
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xae34ae34
Device Boot Start End Blocks Id System
/dev/sda1 * 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 156248189 58581022+ f W95 Ext'd (LBA)
/dev/sda5 39086208 78108029 19510911 7 HPFS/NTFS
/dev/sda6 78108093 78509654 200781 83 Linux
/dev/sda7 78509718 156248189 38869236 8e Linux LVM
From this I can get the number of sectors / track, and calculate the location of the EBRs with a standard partition layout.
Here is the script that I have written that can do this. It is currently hard coded for the disk, but that would be easy to change. It has to make backups of the MBR, and then each of the EBRs for the 4 possible logical partitions. This probable will not work if special partition programs were used.
My ideal would be at the end to make a compressed file of the information created by the script.
disk.info contains the original fdisk -lu information
mbr contains the MBR and physical partition info
ebr5, ebr6, ebr7, and ebr8 would be created for each EBR if present.
rest.mbr is the code that would be required to restore each of these files to the proper location. Assuming one if restore to a new disk.
If these files are compressed into a single file and uploaded to the ftp server, they could then be downloaded, and the rest.mbr could be run to restore both the mbr and physical partitions, but also the logical ones. This would require the number of sectors per track to be the same on the source and destination.
I have not yet tested the restore process, but have looked at the files created and the match up with the expected format of the EBR sectors.
One thing that I am thinking of changing, is to use count=$sectors instead of 1. The MBR and EBR are only suppose to be the 1st sector, but some OS's from what I understand may put stuff in these other sectors. It would increase the size of the files by $sectors - 1, but that would only be 31K for the MBR plus up to 124K if 4 logical partitions are included. So 155K compressed....
Does anyone know of any issues I might be missing???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After the backup with NTFS Clone, the system use the same file name
and add to the end of the file something like .MBR and do the MBRBACKUP
at the same time.
or if not possible
Just add the .MBR extension to the file name wan we do the MBRBACKUP
so we don't have to go back after the NTFSCLONE to enter again the new
file name for the MBRBACKUP.
I tried the new version 0.3 beta 33 and it look like it's working fine.
Good job man , this new function for the MBR is rely appreciated.
I was doing the MBR backup manually.
^_^
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That would be possible, but an mbr backup would only need to be done if the partition layout of the disk was changed. So, it would only need to be done once, and unless there was change to the MBR or partition table. So, making it automatic everytime a backup is done. Additionally, it would require running the mbr restore option to put it back.
Will have to look at it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been working with a user on adding MBR backup options to the G4L, and have done so on the network menu. I've combined the B: and C: into just B:. Normally, it already gets the IP via DHCP, but if one now leaves the IP address BLANK, it will redo the dhcp. Did this to keep all options on Screen.
ftp://202.128.73.28/g4l-v0.30alpha32.iso
(includes kernel 2.6.29.1 and syslinux 3.74 pre 17)
This has the updated script with the new M: Option, but it only backs up the MBR and Physical partition table that is contained in the first 512 bytes of the disk. It Does not backup the logical partitions that are stored in EBRs on the disk at various locations. So, if you have only physical partitions this should work, but any logical partitions will not be included, so in that case you must do a full disk backup or manually create the partitions.
Now as for an update on the solutions that I am working on to fix this...
On my systems, I have the following partitions as reported by fdisk.
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xae34ae34
Device Boot Start End Blocks Id System
/dev/sda1 * 1 2433 19543041 c W95 FAT32 (LBA)
/dev/sda2 2434 9726 58581022+ f W95 Ext'd (LBA)
/dev/sda5 2434 4862 19510911 7 HPFS/NTFS
/dev/sda6 4863 4887 200781 83 Linux
/dev/sda7 4888 9726 38869236 8e Linux LVM
As you can see there are 3 logical partitions. The physical partitions would be included in the first 512 bytes, but not the 3 Logical partitions.
fdisk -lu /dev/sda shows the absolute sector numbers of the disk layout.
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xae34ae34
Device Boot Start End Blocks Id System
/dev/sda1 * 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 156248189 58581022+ f W95 Ext'd (LBA)
/dev/sda5 39086208 78108029 19510911 7 HPFS/NTFS
/dev/sda6 78108093 78509654 200781 83 Linux
/dev/sda7 78509718 156248189 38869236 8e Linux LVM
From this I can get the number of sectors / track, and calculate the location of the EBRs with a standard partition layout.
Here is the script that I have written that can do this. It is currently hard coded for the disk, but that would be easy to change. It has to make backups of the MBR, and then each of the EBRs for the 4 possible logical partitions. This probable will not work if special partition programs were used.
Working script test.mbr
disk=sda
sectors=
fdisk -lu /dev/$disk | grep sectors/track | cut -f 3 -d\part5=
fdisk -lu /dev/$disk | grep "$disk"5 | cut -b 10-25part6=
fdisk -lu /dev/$disk | grep "$disk"6 | cut -b 10-25part7=
fdisk -lu /dev/$disk | grep "$disk"7 | cut -b 10-25part8=
fdisk -lu /dev/$disk | grep "$disk"8 | cut -b 10-25echo $sectors
fdisk -lu /dev/$disk >disk.info
echo #Restore mbr >rest.mbr
dd if=/dev/$disk of=mbr bs=512 count=1
echo dd of=/dev/$disk if=mbr bs=512 >>rest.mbr
if [ -n "$part5" ] ; then
ebr5=
expr $part5 - $sectorsecho $part5 $ebr5
dd if=/dev/$disk of=ebr5 bs=512 skip=$ebr5 count=1
echo dd of=/dev/$disk if=ebr5 bs=512 skip=$ebr5 >>rest.mbr
fi
if [ -n "$part6" ] ; then
ebr6=
expr $part6 - $sectorsecho $part6 $ebr6
dd if=/dev/$disk of=ebr6 bs=512 skip=$ebr6 count=1
echo dd of=/dev/$disk if=ebr6 bs=512 skip=$ebr6 >>rest.mbr
fi
if [ -n "$part7" ] ; then
ebr7=
expr $part7 - $sectorsecho $part7 $ebr7
dd if=/dev/$disk of=ebr7 bs=512 skip=$ebr7 count=1
echo dd of=/dev/$disk if=ebr7 bs=512 skip=$ebr7 >>rest.mbr
fi
if [ -n "$part8" ] ; then
ebr8=
expr $part8 - $sectorsecho $part8 $ebr8
dd if=/dev/$disk of=ebr8 bs=512 skip=$ebr8 count=1
echo dd of=/dev/$disk if=ebr8 bs=512 skip=$ebr8 >>rest.mbr
fi
My ideal would be at the end to make a compressed file of the information created by the script.
disk.info contains the original fdisk -lu information
mbr contains the MBR and physical partition info
ebr5, ebr6, ebr7, and ebr8 would be created for each EBR if present.
rest.mbr is the code that would be required to restore each of these files to the proper location. Assuming one if restore to a new disk.
If these files are compressed into a single file and uploaded to the ftp server, they could then be downloaded, and the rest.mbr could be run to restore both the mbr and physical partitions, but also the logical ones. This would require the number of sectors per track to be the same on the source and destination.
I have not yet tested the restore process, but have looked at the files created and the match up with the expected format of the EBR sectors.
One thing that I am thinking of changing, is to use count=$sectors instead of 1. The MBR and EBR are only suppose to be the 1st sector, but some OS's from what I understand may put stuff in these other sectors. It would increase the size of the files by $sectors - 1, but that would only be 31K for the MBR plus up to 124K if 4 logical partitions are included. So 155K compressed....
Does anyone know of any issues I might be missing???
Hi Michael,
It would be nice to have something like.
After the backup with NTFS Clone, the system use the same file name
and add to the end of the file something like .MBR and do the MBRBACKUP
at the same time.
or if not possible
Just add the .MBR extension to the file name wan we do the MBRBACKUP
so we don't have to go back after the NTFSCLONE to enter again the new
file name for the MBRBACKUP.
I tried the new version 0.3 beta 33 and it look like it's working fine.
Good job man , this new function for the MBR is rely appreciated.
I was doing the MBR backup manually.
^_^
That would be possible, but an mbr backup would only need to be done if the partition layout of the disk was changed. So, it would only need to be done once, and unless there was change to the MBR or partition table. So, making it automatic everytime a backup is done. Additionally, it would require running the mbr restore option to put it back.
Will have to look at it.