Backup and restore | Unix Linux Forums | AIX

  Go Back    


AIX AIX is IBM's industry-leading UNIX operating system that meets the demands of applications that businesses rely upon in today's marketplace.

Backup and restore

AIX


Tags
aix, unix

Closed Thread    
 
Thread Tools Search this Thread Display Modes
    #1  
Old 10-08-2011
polar polar is offline
Registered User
 
Join Date: Aug 2011
Last Activity: 4 February 2013, 10:23 PM EST
Posts: 22
Thanks: 1
Thanked 0 Times in 0 Posts
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.
Sponsored Links
    #2  
Old 10-08-2011
rbatte1 rbatte1 is offline Forum Staff  
Moderator
 
Join Date: Jun 2007
Last Activity: 29 August 2014, 12:30 PM EDT
Location: Lancashire, UK
Posts: 1,754
Thanks: 562
Thanked 298 Times in 267 Posts
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
Sponsored Links
    #3  
Old 10-08-2011
polar polar is offline
Registered User
 
Join Date: Aug 2011
Last Activity: 4 February 2013, 10:23 PM EST
Posts: 22
Thanks: 1
Thanked 0 Times in 0 Posts
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.
    #4  
Old 10-10-2011
rbatte1 rbatte1 is offline Forum Staff  
Moderator
 
Join Date: Jun 2007
Last Activity: 29 August 2014, 12:30 PM EDT
Location: Lancashire, UK
Posts: 1,754
Thanks: 562
Thanked 298 Times in 267 Posts
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
Sponsored Links
    #5  
Old 10-12-2011
polar polar is offline
Registered User
 
Join Date: Aug 2011
Last Activity: 4 February 2013, 10:23 PM EST
Posts: 22
Thanks: 1
Thanked 0 Times in 0 Posts
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.
Sponsored Links
    #6  
Old 10-12-2011
rbatte1 rbatte1 is offline Forum Staff  
Moderator
 
Join Date: Jun 2007
Last Activity: 29 August 2014, 12:30 PM EDT
Location: Lancashire, UK
Posts: 1,754
Thanks: 562
Thanked 298 Times in 267 Posts
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:-

Code:
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:-

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

on your live server, or

Code:
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

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.:-

Code:
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:-

Code:
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
The Following User Says Thank You to rbatte1 For This Useful Post:
polar (10-12-2011)
Sponsored Links
    #7  
Old 10-12-2011
juredd1 juredd1 is offline
Registered User
 
Join Date: Mar 2010
Last Activity: 18 June 2013, 8:29 PM EDT
Posts: 94
Thanks: 4
Thanked 6 Times in 6 Posts
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.
Sponsored Links
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
HMC backup/restore balaji_prk AIX 4 02-03-2009 12:51 AM
SCO 6. Backup & Restore from USB miles556 SCO 3 10-07-2008 06:33 PM
AIX backup and restore quickfirststep AIX 3 09-07-2006 06:59 PM
F-Backup restore paultittel HP-UX 3 06-27-2006 09:46 AM
Cannot restore a TAR backup Ross.Goodman UNIX for Dummies Questions & Answers 2 10-20-2000 04:52 AM



All times are GMT -4. The time now is 06:16 AM.