Backup and restore

Hi experts, i got a question.

i have a production server with two Volume Group(VG) which are rootvg and datavg. Both of these VGs are 256 PP SIZE.

On Disaster Recovery Server (DR server) contains two empty hardisks for restoring rootvg and datavg from production server. This two hardisks are SAN storage DS5020 with set 128 PP SIZE.

So, can i restore the rootvg and datavg on DR Server with different PP SIZE? Any effects for future used?

thanks for reply. appreciate.

Assuming that this is AIX, you define the PP size when creating/restoring the volume groups. There are a few issues to consider though:-

1. Have you got a mirrored rootvg?
   . If so, then you have a problem. It will require two disks to restore to and create the mirrors. You cannot stop this without serious hacking before the backup is taken.
   . If you are not mirrored on the live server then you could lose the server with a single disk failure. Generally on a system with 10 local disks, you can expect a failure on one of them every 3 years. Fewer disks I suppose means there are less to go wrog, so perhaps a lesser risk (arguable) but then you have much more chance of it being catastrophic. Do you feel lucky?
2. Is your rootvg definition up to date?
   . Make sure you run mkszfile before the mksysb to ensure that the defintion is recreated. If you don't and fileystems have been grown, then it is possible that the data will not fit in based on the old definition.
3. How are you restoring your datavg?.
   You can either use savevg to grab the lot, or you can use savevg to save just the structure, allowing you to use a bespoke backup or 3rd party software to backup the data. The same issues over mirrors a sufficient disks to recover to exist. There are options to work on removing mirrors as I have this issue too in that live server is local mirrored disk, DR is SAN provided disks, so RAID behind the scenes means I do not need AIX mirrors.

Can you describe a bit more what you have and/or need.

Robin
Liverpool/Blackburn

this is what in my system

1. production server
   -hdisk0(rootvg)
   -hdisk1(rootvg) (mirrored)
   -hdisk2(datavg)
   -hdisk3(datavg)
   PP SIZE for these two VG is 256MB

2. DR server
   -hdisk0 ( prepare for restore unmirrored rootvg)
   -hdisk1 ( prepare for datavg)
   When setting SAN storage i have defined 128MB as PP SIZE for hdisk0 and hdisk1

My solution is like this:
1.back up mirrored hdisk0 hdisk1 with mksysb in (tape no.1)
2.back up datavg hdisk2 hdisk3 ( tape no.2 for DR server hdisk1)
--break mirror/unmirror hdisk1--
3.back up unmirrored hdisk0 only( tape no.3 for DR server hdisk0 used)

question: would it influence DR server hdisk0 and hdisk1 since PP SIZE is 128MB but backup from production server is 256MB.

Hmmm, not a good starting point.

The good news is that the SAN definition of PP size should be irrelevant. It might cost you a little bit of usable space, but that's probably minimal. Your problem will be that you are moving from AIX LV mirrors to hardware mirrors (however the SAN protects the allocated disk) so I have a question about you backup process.

Do you use mkszfile before each mksysb? If so, then you may have got a way round things, but you are still exposing yourself to risks of hdisk0 failing during the backup before the mirror on hdisk1 is complete. Removing the mirrors will clear the disk, so it's not like a split mirror that some other systems have or Veritas can provide. You must also remember to use bosboot and check the bootlist after the mirror.

It might be better to:-

1. Run mksysfile to generate an up-to-date configuration file, mirrors and all.
2. Edit /image.data and set all COPIES= 2 statements to be COPIES= 1
3. Run mksysb

Be aware that your tape will only create a single copy, so if you recover to a machine without hardware protected boot disk, you would need to manaully mirror afterwards, including the bosboot and edit of the bootlist If you have to recover to your live system, install to a single disk rather that risk the restore spreading out over both disks.

For your data volume group, it is unclear if the logical volumes are mirrored or how you back them up. If not mirrored, then you are exposed to hardware failure at any time. If they are, then you can perform similar actions, but it would be good to know the backup method for the data before I leap into something. What would your DR recovery procedure be like too? It's all well and good to say you have a backup, but have you tested your restore plan?

Let me know what you have in place and I will see about other suggestions to further protect you. Is it savevg, tar, cpio or perhaps a 3rd party backup tool?

Robin
Liverpool/Blackburn
UK

production with:
-hdisk0(rootvg)
-hdisk1(rootvg) [mirrored]
-hdisk2(datavg)
-hdisk3(datavg)

My solution's steps for production server backup:
1.I was first unmirrored and reducevg hdisk1
2.Backup hdisk0 using command 'smitty mksysb'
3.Backup hdisk2 and hdisk3 using command 'smitty savevg'
# using internal tape drive DAT320 with tape DAT160
a)rootvg 1 tape used
b)datavg 2 tapes used

My solution's steps for DR server restore:
1.Restore hdisk0 with rootvg using command SMS mode
2.Restore hdisk1 with datavg using command 'smitty restvg'
#using SAS 7214-1U2 Tape drive DAT160

conclusion:
Restoring rootvg was successful BUT datavg was completed with error shown which is error 0511-133[The media surface is damage ignoring data and continuing..] after few lines it prompted this error it comes to the end showing that restoring completed without shoing me to insert volume2 tape.

Eeeek! - You are leaving yourself at risk with this process.

Might I make a suggestion the you (as root) create an empty directory /disaster and a file /etc/exclude.datavg containing just ^\./ It is a circumflex/hat/funny accent to define beggining of line, then a backslash, fullstop then a forward slash. No trailling spaces. When savevg runs with the -e flag, it will use this file to exclude the contents of the datavg filesystems. Then:-

mkszfile
savevg -ef /disaster/datavg.structure datavg                  # Save mirrored definition
echo ":%s /COPIES= 2/COPIES= 1\n:wq"|vi /tmp/vgdata/datavg/datavg.data
savevg -ef /disaster/datavg.structure_nomirror datavg         # Save un-mirrored definition

mksysb /dev/rmt0                                              # Backup for recovery to mirrored rootvg disks 
echo ":%s /COPIES= 2/COPIES= 1\n:wq"|vi /image.data
mksysb /dev/rmt0                                              # Backup for recovery single rootvg disk

Now you will notice that there are savevg commands here. These save the definition of your volume group (logical volumes, filesystems etc.) but no data. The files created will be recovered when you restore your mksysb so you have a starting point. You can then issue:-

restvg -q -f /disaster/datavg.structure hdisk2 hdisk3

on your live server, or

restvg -q -f /disaster/datavg.structure_nomirror hdisk1

on the DR server. This will recreate and mount the empty filesystems ready ready for a data restore. Obviously, the disks have to be empty and not part of a volume group to do this, so it is probably only theoretical for your live server. Don't use it unless you have to :rolleyes:

Now obviously you have to consider the data backup/restore process. In my experience, savevg is not the neatest because (I think) you have to restore the whole volume group and that could be a problem if you are just after a single file. Use tar, cpio, or backup & restore to save your data. You can also then split it up over different media and be confident that you can restore single files if required.

You could do the following to get the filesystems you need to backup with tar/cpio etc.:-

lsvg -l datavg |grep open |tr -s " " |cut -f7 -d " " |sort

The rest is up to you really on how you want to play it. I would not necessarily advise avoiding smit completely, more trying to learn what it is doing for you and scripting that up instead. Have a look at smit.script that grows with each command. It will give you a better understanding of what you are asking the server to do.

It should at least reduce the risk to your server during the backup window. Additionally, smit panels are pretty difficult to schedule, so you could end up either staying on-site after business hours (including any schedule) to press the buttons and set it off or risk taking a backup of a moving target.

Does this help?

I think that your description suggests that your data is on plain unmirrored disks. Is that correct? If so then you are at risk there too. I regret that it is probably time to spend some money to protect yourself from a disk failure. If not, can you post the output from:-

lsvg -p datavg
lsvg -l datavg

... so we can see what can be done.

Can anyone else tidy up my procedure, suggest more information (correct any errors too) or help fill this out to better secure the position of this server?

Robin
Liverpool/Blackburn
UK

If your rootvg at your production site is set to "PP SIZE = 256MB" then when the mksysb restore runs it will automatically create the rootvg at the DR server with a PP SIZE of 256mb as long as the disk is not two large to allow that. Why not just leave the disks mirrored on your prod server and use both disks on your DR server and after the mksysb restore just unmirror rootvg and reduce hdisk1 to free up the extra disk?

If the restore from tape for datavg is not working make sure the block size on the tape drive on the DR server is the same as the block size on the tape drive you created the tapes on. This bit me last month during my DR exercise.

thank for guys replying useful information. appreciate

rbatte1: Thanks for your sharing, i will note down your solutions for future use because i have done the backup and restore successfully.By hook or by or by crook really appreciate.

juredd1: rootvg restored completed with PP SIZE 256MB but datavg with PP SIZE 512MB. weird. @.@ and because i'm using SAN storage with RAID5 configuration so i do not get the mirrored hdisk1 restore on DR server to avoid hitting errors.