Difference between revisions of "UpgradeDisk"

From SME Server
Jump to navigationJump to search
m (Fixed reference to reflect correct bug report.)
 
(42 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
==Upgrade Disk==
 
==Upgrade Disk==
  
 +
{{Warning box|If you were looking for the details of Adding a larger Hard Disk Drive (HDD) to an existing Raid or Upgrading the HDD of an existing RAID  array - Look Here: http://wiki.contribs.org/Raid#Upgrading_the_Hard_Drive_Size}} 
 +
 +
===Introduction===
 
Hard drive restore requires a complete system.  It is meant to take a hard
 
Hard drive restore requires a complete system.  It is meant to take a hard
 
drive from a system, mount it, and do a restore from it.  
 
drive from a system, mount it, and do a restore from it.  
  
−
It does not restore contribs or manually added software, except if it's in an Ibay and instructs you to move custom-templates.  
+
It's always better to use a backup and restore from there, but...
 +
 
 +
It does not restore contribs or manually added software, except if it's in an Ibay and instructs you to move custom-templates. Pay special attention to contribs that store data files in /opt as this will not move automatically thus after remounting the old drive you may need to move the data files over after you have re-installed the contribs.
 +
 
 +
The restore includes mysql databases even for contribs. Thus after the restore if you re-add the same contribs (save version too) then your contribs should be able to access their mysql database. If you upgrade the contrib at the same time then note that contrib's upgrade procedures for it's database. Note comment in regards /opt above.
 +
 
 +
This instruction is MUCH easier to use, when a SME 7x cd is used a an emergency recovery boot system.
  
 +
=== Moving from SME 6.x to SME 7.x ===
 
Summarised from http://forums.contribs.org/index.php?topic=30745.0
 
Summarised from http://forums.contribs.org/index.php?topic=30745.0
  
−
# On the old SME server prior to shutting down do  '''signal-event pre-backup''' then shutdown & remove the drive
+
The following instructions were first developed when people were moving from 6.x to 7.0. At that time the templates directory had changed between versions.
 +
 
 +
# On the old SME server prior to shutting down, at the root command prompt issue the command '''/sbin/e-smith/signal-event [[UpgradeDisk#Recovering_a_system_where_pre-backup_could_not_be_run|pre-backup]]''' then shutdown & remove the drive
 
# On the new machine do a fresh install of sme7
 
# On the new machine do a fresh install of sme7
 
# Shut down & install old drive and start machine.
 
# Shut down & install old drive and start machine.
 
# mkdir /mnt/tmp
 
# mkdir /mnt/tmp
−
# mount /dev/hdb2 /mnt/tmp (adjust "hdb2" according to where the old drive is installed).
+
# mount /dev/hdxn /mnt/tmp (adjust "hdxn" according to which channel the drive is connected to and which partition the data on the old drive is located ie use fdisk -l /dev/hdx to determine this, usually it will be the largest partition, in most cases this will be /dev/hda2 but in some cases may be /dev/hda3).
 
# db configuration setprop backup Program CopyFromDisk status enabled
 
# db configuration setprop backup Program CopyFromDisk status enabled
 
# signal-event pre-restore
 
# signal-event pre-restore
Line 25: Line 37:
 
# Shutdown and remove old drive
 
# Shutdown and remove old drive
  
 +
=== Moving from SME 7.x to SME 7.x ===
 +
In this case your template directories and other structures should not have to change thus the template directory changes are not needed. However SME 7 does use LVM and you will by default end up with an LVM group name conflict, thus new steps are added to rename the LVM group name on the old disk.
  
−
Additional tips from http://forums.contribs.org/index.php?topic=39892.0
+
# On the old SME server prior to shutting down, at the root command prompt issue the command '''/sbin/e-smith/signal-event [[UpgradeDisk#Recovering_a_system_where_pre-backup_could_not_be_run|pre-backup]]''' then shutdown & remove the drive
−
which refers to http://forums.contribs.org/index.php?topic=37686.0
+
# On the new machine do a fresh install of sme7
 +
# Shut down & install old drive.
  
−
The original disk will not mount due to volume group name conflicts with the existing drive(s).
+
Boot from SME Server 7.x install CD
−
Follow this procedure to rename the volume group on the original disk:
 
−
 
 
−
Boot from SME Server 7.1 (or newer) install CD
 
  
 
press F5
 
press F5
  
 
type "sme rescue" at the command prompt and hit enter
 
type "sme rescue" at the command prompt and hit enter
 +
 +
{{Note box|don't start the network and skip mounting the filesystem.}}
 +
{{Note box|If you are on a newer board the disk may show up on /dev/sd'''x''' so the reference to hdx2 should be changed to sd'''x'''2; where you need to change "'''x'''" to the appropriate letter to match the the disk.
 +
 +
when you do the "lvm vgscan" the LVM name should be "main" thus the value "orig_vg_name" should be "main". If it is different then use the appropriate LVM name.}}
 +
 +
mdadm -AR /dev/md5 /dev/'''hdx'''2
 +
lvm vgscan
 +
lvm vgs -v
 +
lvm vgchange -a n
 +
lvm vgrename orig_vg_name new_vg_name
 +
exit
 +
 +
Now remove the CD and reboot.
 +
 +
{{Note box|In most cases you won't need the mdadm, vgscan, vgchange commands below but they won't hurt. If you get an error with mdadm in regards to md5 being busy it is likely because your drive was automatically mounted. If the mount command works and you can see your data on it then it worked.
 +
 +
don't forget that "new_vg_name" references below should be whatever you used above.}}
 +
 +
mdadm -AR /dev/md5 /dev/'''hdx'''2
 +
vgscan
 +
vgchange -a y new_vg_name
 +
mkdir /mnt/old
 +
mount /dev/new_vg_name/root /mnt/old
 +
 +
# db configuration setprop backup Program CopyFromDisk status enabled
 +
# signal-event pre-restore
 +
# signal-event restore-tape /mnt/old (note: this step may take a long time depending on how much data is being restored
 +
# signal-event post-upgrade
 +
# signal-event reboot
 +
# Shutdown and remove old drive
 +
 +
=== Moving from SME 7.x to SME 8.x ===
 +
 +
See this thread:
 +
 +
http://forums.contribs.org/index.php/topic,46531.0.html
 +
 +
and this Bug :
 +
 +
http://bugs.contribs.org/show_bug.cgi?id=6195
 +
 +
With SME 8 being based on CentOS 5, assembling the RAID in rescue mode must be specified using the disk's UUID. If you have the SME 7 CD it will be easier to rename the Volume Group using it per the instructions below. Otherwise use the SME 8 procedure.
 +
 +
{{Note box|Before you start,  It might be worth fscking the disk/s to ensure that there are no errors.}}
 +
 +
# Make sure you have a very good backup
 +
# signal-event [[UpgradeDisk#Recovering_a_system_where_pre-backup_could_not_be_run|pre-backup]] on the old installation
 +
# Boot with a SME7 CD or SME 8 CD and only one of your original disks (in the case of a RAID1 arrangement)
 +
# As per instructions in "Boot from SME Server 7.1 (or newer) install CD" above :
 +
 +
Type "sme rescue" at the command prompt and hit enter
  
 
Note: don't start the network and skip mounting the filesystem.
 
Note: don't start the network and skip mounting the filesystem.
  
 +
If using SME 7 CD
 
  mdadm -AR /dev/md5 /dev/hdx2
 
  mdadm -AR /dev/md5 /dev/hdx2
 +
 +
If using SME 8 CD  (see [[bugzilla: 6195]])
 +
mdadm --examine /dev/sda# | grep 'UUID'
 +
mdadm -AR --uuid '''the:uuid:value:from:above''' /dev/md5
 +
 +
Next Steps
 
  lvm vgscan
 
  lvm vgscan
 
  lvm vgs -v
 
  lvm vgs -v
Line 47: Line 118:
 
  exit
 
  exit
  
−
Now remove the CD and reboot
+
Now remove the CD and reboot into SME 8 :
  
−
  mdadm -AR /dev/md5 /dev/hdx2
+
  mdadm -AR /dev/md5 /dev/hdx2 (n.b. you may find that /dev/md5 already exists)
 +
vgscan
 +
vgchange -a y new_vg_name
 +
mkdir /mnt/tmp
 +
mount /dev/new_vg_name/root /mnt/tmp
 +
 
 +
{{Note box|In some rare cases your VolumeGroup name listed in the last line might be different, more information can be found in [[[[bugzilla: 3883]]]].}}
 +
 
 +
You should now be able to view all your old data under /mnt/tmp
 +
 
 +
db configuration setprop backup Program CopyFromDisk status enabled
 +
signal-event pre-restore
 +
signal-event restore-tape /mnt/tmp (note: this step may take a long time depending on how much data is being restored
 +
signal-event post-upgrade
 +
signal-event reboot
 +
 
 +
Shutdown and remove old drive and reboot
 +
 
 +
All the usual warnings apply. Remember that any old contribs & templates will have to be reinstalled (assuming that they will work with V8)
 +
 
 +
=== Moving from SME 8.x to SME 9.x ===
 +
 
 +
SME 9 entails the same issues as SME 8 (see above):
 +
 
 +
With SME 8 being based on CentOS 5, assembling the RAID in rescue mode must be specified using the disk's UUID. If you have the SME 7 CD it will be easier to rename the Volume Group using it per the instructions below. Otherwise use the SME 8 procedure.
 +
 
 +
{{Note box|Before you start,  It might be worth fscking the disk/s to ensure that there are no errors.}}
 +
 
 +
# Make sure you have a very good backup
 +
# signal-event [[UpgradeDisk#Recovering_a_system_where_pre-backup_could_not_be_run|pre-backup]] on the old installation
 +
# Boot with a SME7 CD or SME 8 CD and only one of your original disks (in the case of a RAID1 arrangement)
 +
# As per instructions in "Boot from SME Server 7.1 (or newer) install CD" above :
 +
 
 +
Type "sme rescue" at the command prompt and hit enter
 +
 
 +
Note: don't start the network and skip mounting the filesystem.
 +
 
 +
If using SME 7 CD
 +
mdadm -AR /dev/md5 /dev/sdx2
 +
 
 +
If using SME 8 CD  (see [[bugzilla: 6195]])
 +
mdadm --examine /dev/sda# | grep 'UUID'
 +
mdadm -AR --uuid '''the:uuid:value:from:above''' /dev/md5
 +
 
 +
If using SME 9 CD  (see [[bugzilla: 6195]])
 +
mdadm --examine /dev/sda# | grep 'UUID'
 +
mdadm -AR --uuid '''the:uuid:value:from:above''' /dev/md5
 +
 
 +
Next Steps
 +
lvm vgscan
 +
lvm vgs -v
 +
lvm vgchange -a n
 +
lvm vgrename main new_vg_name
 +
exit
 +
 
 +
Now remove the CD and reboot into SME 9 :
 +
 
 +
mdadm -AR /dev/md5 /dev/sdx2 (n.b. you may find that /dev/md5 already exists)
 
  vgscan
 
  vgscan
 
  vgchange -a y new_vg_name
 
  vgchange -a y new_vg_name
 
  mkdir /mnt/tmp
 
  mkdir /mnt/tmp
 
  mount /dev/new_vg_name/root /mnt/tmp
 
  mount /dev/new_vg_name/root /mnt/tmp
−
{{Note box|In some rare cases your VolumeGroup name listed in the last line might be different, more information can be found in [[bugzilla: 3883]].}}
+
 
 +
{{Note box|In some rare cases your VolumeGroup name listed in the last line might be different, more information can be found in [[[[bugzilla: 3883]]]].}}
  
 
You should now be able to view all your old data under /mnt/tmp
 
You should now be able to view all your old data under /mnt/tmp
  
−
Follow the steps listed above to use CopyFromDisk to restore the data.
+
db configuration setprop backup Program CopyFromDisk status enabled
 +
signal-event pre-restore
 +
signal-event restore-tape /mnt/tmp (note: this step may take a long time depending on how much data is being restored
 +
signal-event post-upgrade
 +
signal-event reboot
 +
 
 +
Shutdown and remove old drive and reboot
 +
 
 +
All the usual warnings apply. Remember that any old contribs & templates will have to be reinstalled (assuming that they will work with V9)
 +
 
 +
January 2015: I was forced to use this method to recover a 6 year old server running SME 8, the hardware RAID had fried, not only listing a working RAID, AND leaving the second disk empty. It also deleted the last working disk! And NO usuable backups at all...
 +
Testdisk helped with the erased disk. I used a SME 7.6 disk to rename the vg. Using the procedure above on the same server with new disks took it's time, but: Everything works! Running the latest & greatest SME 9 now...
 +
 
 +
===Using a third drive===
 +
I have just repeated the exercise and it seems to work OK. It was much easier having a third drive. Mark the drives so you know what each contains! I will refer to them as A, B & C - substitute the relevant drive paths accordingly.
 +
 
 +
I did the following :
 +
#Added the third drive (C) as a hot spare - see : http://wiki.contribs.org/Raid#Adding_another_Hard_Drive_Later
 +
#Stop the machine, remove one drive (B) and restart - this makes the array 'fail' and the hot spare will be added to the array and mirrored. Run the pre-backup for (A) & (C). Stop the machine.
 +
#Remove the SME7 drives (A) & (C). Install SM8 on the first pulled drive (B) and apply any updates.
 +
#Stop the machine. Pull the original disk (A) and store it out of the way - you can always get yourself back with this drive. It is better to save (A) as (C) may not have a boot partition correctly installed - see the notes on adding a hot spare : http://forums.contribs.org/index.php/topic,38041.msg171631.html#msg171631
 +
#Reboot with an SME7 CD (see above for details) and the 'new' drive (C) and rename the LVM on it as detailed above.
 +
#Stop the machine. Plug in the disk with SME8 (B) and the disk with SME7 (C). Boot from the SME8 disk (B). Mount the LVM on the SME7 disk (C) as above and restore from disk (C).
 +
#Check that the data has copied over OK, format disk (C) to wipe the old system and then add it to the SME 8 Array.
 +
#Finally once you are happy everything is working add back Disk (A)
 +
 
 +
===Recovering a system where pre-backup could not be run===
 +
{{Warning box| Only use this procedure where pre-backup cannot be run eg in the event of a corrupt filesystem and/or unbootbale server}}
 +
 
 +
This addresses the situation where the pre-backup was unable to be run eg a sudden power outage that has caused a corrupt filesystem and unbootable server, it concerns the recovery of your mysql db's . It should not be the general case for the procedure of Upgrading a Disk, only if you are in a recovery situation where pre-backup is not an option. The mysql db's are kept in: /var/lib/mysql.
 +
 
 +
Stop the mysql service:
 +
  service mysqld stop
 +
Change directories to the old mysql:
 +
cd /mnt/old/var/lib/
 +
Copy the mysql db's to the new install:
 +
cp -R ./mysql /var/lib/
 +
Change directories to the new mysql:
 +
  cd /var/lib/
 +
Change the ownership on the new install mysql directory:
 +
  chown -R mysql:mysql ./mysql
 +
Restart the mysqld service:
 +
  service mysqld start
 +
 
 +
==Reference information==
 +
Additional tips from http://forums.contribs.org/index.php?topic=39892.0
 +
which refers to http://forums.contribs.org/index.php?topic=37686.0
 +
 
 +
To understand more of the background of LVM and RAID data recovery, read this:
 +
 
 +
http://www.linuxjournal.com/article/8874
 
----
 
----
 
[[Category:Howto]]
 
[[Category:Howto]]
 +
[[Category:Backup]]
 +
[[Category:Administration:Storage]]

Latest revision as of 03:35, 27 May 2022

Upgrade Disk

Warning.png Warning:
If you were looking for the details of Adding a larger Hard Disk Drive (HDD) to an existing Raid or Upgrading the HDD of an existing RAID array - Look Here: http://wiki.contribs.org/Raid#Upgrading_the_Hard_Drive_Size


Introduction

Hard drive restore requires a complete system. It is meant to take a hard drive from a system, mount it, and do a restore from it.

It's always better to use a backup and restore from there, but...

It does not restore contribs or manually added software, except if it's in an Ibay and instructs you to move custom-templates. Pay special attention to contribs that store data files in /opt as this will not move automatically thus after remounting the old drive you may need to move the data files over after you have re-installed the contribs.

The restore includes mysql databases even for contribs. Thus after the restore if you re-add the same contribs (save version too) then your contribs should be able to access their mysql database. If you upgrade the contrib at the same time then note that contrib's upgrade procedures for it's database. Note comment in regards /opt above.

This instruction is MUCH easier to use, when a SME 7x cd is used a an emergency recovery boot system.

Moving from SME 6.x to SME 7.x

Summarised from http://forums.contribs.org/index.php?topic=30745.0

The following instructions were first developed when people were moving from 6.x to 7.0. At that time the templates directory had changed between versions.

  1. On the old SME server prior to shutting down, at the root command prompt issue the command /sbin/e-smith/signal-event pre-backup then shutdown & remove the drive
  2. On the new machine do a fresh install of sme7
  3. Shut down & install old drive and start machine.
  4. mkdir /mnt/tmp
  5. mount /dev/hdxn /mnt/tmp (adjust "hdxn" according to which channel the drive is connected to and which partition the data on the old drive is located ie use fdisk -l /dev/hdx to determine this, usually it will be the largest partition, in most cases this will be /dev/hda2 but in some cases may be /dev/hda3).
  6. db configuration setprop backup Program CopyFromDisk status enabled
  7. signal-event pre-restore
  8. signal-event restore-tape /mnt/tmp (note: this step may take a long time depending on how much data is being restored
  9. cd /etc/e-smith
  10. mv templates-custom templates-custom.old
  11. mkdir templates-custom
  12. mv templates-user-custom templates-user-custom.old
  13. mkdir templates-user-custom
  14. signal-event post-upgrade
  15. signal-event reboot
  16. Shutdown and remove old drive

Moving from SME 7.x to SME 7.x

In this case your template directories and other structures should not have to change thus the template directory changes are not needed. However SME 7 does use LVM and you will by default end up with an LVM group name conflict, thus new steps are added to rename the LVM group name on the old disk.

  1. On the old SME server prior to shutting down, at the root command prompt issue the command /sbin/e-smith/signal-event pre-backup then shutdown & remove the drive
  2. On the new machine do a fresh install of sme7
  3. Shut down & install old drive.

Boot from SME Server 7.x install CD

press F5

type "sme rescue" at the command prompt and hit enter


Important.png Note:
don't start the network and skip mounting the filesystem.


Important.png Note:
If you are on a newer board the disk may show up on /dev/sdx so the reference to hdx2 should be changed to sdx2; where you need to change "x" to the appropriate letter to match the the disk.

when you do the "lvm vgscan" the LVM name should be "main" thus the value "orig_vg_name" should be "main". If it is different then use the appropriate LVM name. 


mdadm -AR /dev/md5 /dev/hdx2
lvm vgscan
lvm vgs -v
lvm vgchange -a n
lvm vgrename orig_vg_name new_vg_name
exit

Now remove the CD and reboot.


Important.png Note:
In most cases you won't need the mdadm, vgscan, vgchange commands below but they won't hurt. If you get an error with mdadm in regards to md5 being busy it is likely because your drive was automatically mounted. If the mount command works and you can see your data on it then it worked.

don't forget that "new_vg_name" references below should be whatever you used above. 


mdadm -AR /dev/md5 /dev/hdx2
vgscan
vgchange -a y new_vg_name
mkdir /mnt/old
mount /dev/new_vg_name/root /mnt/old
  1. db configuration setprop backup Program CopyFromDisk status enabled
  2. signal-event pre-restore
  3. signal-event restore-tape /mnt/old (note: this step may take a long time depending on how much data is being restored
  4. signal-event post-upgrade
  5. signal-event reboot
  6. Shutdown and remove old drive

Moving from SME 7.x to SME 8.x

See this thread:

http://forums.contribs.org/index.php/topic,46531.0.html

and this Bug :

http://bugs.contribs.org/show_bug.cgi?id=6195

With SME 8 being based on CentOS 5, assembling the RAID in rescue mode must be specified using the disk's UUID. If you have the SME 7 CD it will be easier to rename the Volume Group using it per the instructions below. Otherwise use the SME 8 procedure.


Important.png Note:
Before you start, It might be worth fscking the disk/s to ensure that there are no errors.


  1. Make sure you have a very good backup
  2. signal-event pre-backup on the old installation
  3. Boot with a SME7 CD or SME 8 CD and only one of your original disks (in the case of a RAID1 arrangement)
  4. As per instructions in "Boot from SME Server 7.1 (or newer) install CD" above :

Type "sme rescue" at the command prompt and hit enter

Note: don't start the network and skip mounting the filesystem.

If using SME 7 CD 

mdadm -AR /dev/md5 /dev/hdx2

If using SME 8 CD (see bugzilla: 6195) 

mdadm --examine /dev/sda# | grep 'UUID'
mdadm -AR --uuid the:uuid:value:from:above /dev/md5

Next Steps 

lvm vgscan
lvm vgs -v
lvm vgchange -a n
lvm vgrename orig_vg_name new_vg_name
exit

Now remove the CD and reboot into SME 8 : 

mdadm -AR /dev/md5 /dev/hdx2 (n.b. you may find that /dev/md5 already exists)
vgscan
vgchange -a y new_vg_name
mkdir /mnt/tmp
mount /dev/new_vg_name/root /mnt/tmp


Important.png Note:
In some rare cases your VolumeGroup name listed in the last line might be different, more information can be found in [[bugzilla: 3883]].


You should now be able to view all your old data under /mnt/tmp 

db configuration setprop backup Program CopyFromDisk status enabled
signal-event pre-restore
signal-event restore-tape /mnt/tmp (note: this step may take a long time depending on how much data is being restored
signal-event post-upgrade
signal-event reboot

Shutdown and remove old drive and reboot

All the usual warnings apply. Remember that any old contribs & templates will have to be reinstalled (assuming that they will work with V8)

Moving from SME 8.x to SME 9.x

SME 9 entails the same issues as SME 8 (see above):

With SME 8 being based on CentOS 5, assembling the RAID in rescue mode must be specified using the disk's UUID. If you have the SME 7 CD it will be easier to rename the Volume Group using it per the instructions below. Otherwise use the SME 8 procedure.


Important.png Note:
Before you start, It might be worth fscking the disk/s to ensure that there are no errors.


  1. Make sure you have a very good backup
  2. signal-event pre-backup on the old installation
  3. Boot with a SME7 CD or SME 8 CD and only one of your original disks (in the case of a RAID1 arrangement)
  4. As per instructions in "Boot from SME Server 7.1 (or newer) install CD" above :

Type "sme rescue" at the command prompt and hit enter

Note: don't start the network and skip mounting the filesystem.

If using SME 7 CD 

mdadm -AR /dev/md5 /dev/sdx2

If using SME 8 CD (see bugzilla: 6195) 

mdadm --examine /dev/sda# | grep 'UUID'
mdadm -AR --uuid the:uuid:value:from:above /dev/md5

If using SME 9 CD (see bugzilla: 6195) 

mdadm --examine /dev/sda# | grep 'UUID'
mdadm -AR --uuid the:uuid:value:from:above /dev/md5

Next Steps 

lvm vgscan
lvm vgs -v
lvm vgchange -a n
lvm vgrename main new_vg_name
exit

Now remove the CD and reboot into SME 9 : 

mdadm -AR /dev/md5 /dev/sdx2 (n.b. you may find that /dev/md5 already exists)
vgscan
vgchange -a y new_vg_name
mkdir /mnt/tmp
mount /dev/new_vg_name/root /mnt/tmp


Important.png Note:
In some rare cases your VolumeGroup name listed in the last line might be different, more information can be found in [[bugzilla: 3883]].


You should now be able to view all your old data under /mnt/tmp 

db configuration setprop backup Program CopyFromDisk status enabled
signal-event pre-restore
signal-event restore-tape /mnt/tmp (note: this step may take a long time depending on how much data is being restored
signal-event post-upgrade
signal-event reboot

Shutdown and remove old drive and reboot

All the usual warnings apply. Remember that any old contribs & templates will have to be reinstalled (assuming that they will work with V9)

January 2015: I was forced to use this method to recover a 6 year old server running SME 8, the hardware RAID had fried, not only listing a working RAID, AND leaving the second disk empty. It also deleted the last working disk! And NO usuable backups at all... Testdisk helped with the erased disk. I used a SME 7.6 disk to rename the vg. Using the procedure above on the same server with new disks took it's time, but: Everything works! Running the latest & greatest SME 9 now...

Using a third drive

I have just repeated the exercise and it seems to work OK. It was much easier having a third drive. Mark the drives so you know what each contains! I will refer to them as A, B & C - substitute the relevant drive paths accordingly.

I did the following :

  1. Added the third drive (C) as a hot spare - see : http://wiki.contribs.org/Raid#Adding_another_Hard_Drive_Later
  2. Stop the machine, remove one drive (B) and restart - this makes the array 'fail' and the hot spare will be added to the array and mirrored. Run the pre-backup for (A) & (C). Stop the machine.
  3. Remove the SME7 drives (A) & (C). Install SM8 on the first pulled drive (B) and apply any updates.
  4. Stop the machine. Pull the original disk (A) and store it out of the way - you can always get yourself back with this drive. It is better to save (A) as (C) may not have a boot partition correctly installed - see the notes on adding a hot spare : http://forums.contribs.org/index.php/topic,38041.msg171631.html#msg171631
  5. Reboot with an SME7 CD (see above for details) and the 'new' drive (C) and rename the LVM on it as detailed above.
  6. Stop the machine. Plug in the disk with SME8 (B) and the disk with SME7 (C). Boot from the SME8 disk (B). Mount the LVM on the SME7 disk (C) as above and restore from disk (C).
  7. Check that the data has copied over OK, format disk (C) to wipe the old system and then add it to the SME 8 Array.
  8. Finally once you are happy everything is working add back Disk (A)

Recovering a system where pre-backup could not be run

Warning.png Warning:
Only use this procedure where pre-backup cannot be run eg in the event of a corrupt filesystem and/or unbootbale server


This addresses the situation where the pre-backup was unable to be run eg a sudden power outage that has caused a corrupt filesystem and unbootable server, it concerns the recovery of your mysql db's . It should not be the general case for the procedure of Upgrading a Disk, only if you are in a recovery situation where pre-backup is not an option. The mysql db's are kept in: /var/lib/mysql.

Stop the mysql service: 

 service mysqld stop

Change directories to the old mysql: 

cd /mnt/old/var/lib/

Copy the mysql db's to the new install: 

cp -R ./mysql /var/lib/

Change directories to the new mysql: 

 cd /var/lib/

Change the ownership on the new install mysql directory: 

 chown -R mysql:mysql ./mysql

Restart the mysqld service: 

 service mysqld start

Reference information

Additional tips from http://forums.contribs.org/index.php?topic=39892.0 which refers to http://forums.contribs.org/index.php?topic=37686.0

To understand more of the background of LVM and RAID data recovery, read this:

http://www.linuxjournal.com/article/8874

Retrieved from "https://wiki.koozali.org/index.php?title=UpgradeDisk&oldid=41154"