This post is more than 5 years old

207 Posts

1749

March 12th, 2008 16:00

symclone for backup of database

Hello, we have a dmx1000 connected to AIX servers. We are running a progress database on AIX. Nightly we shutdown the database and back up the file system that the db sits on with veritas netbackup. It takes about 90 minutes. Once the backup is complete we can bring up the progress database and let users access the system.

To save time I would like to shut down the database then clone the database devices and then immediately bring the progress database and application backup after the clone. This should take about a minute rather than 90 minutes. I would then importvg the clone volume group and mount the clone file system on a different host. The volume group and filesystem for the db sit on 3 16-way striped meta volumes.

Once I have mounted the clone file system I will back it up with Veritas netbackup like before. This will still take 90+ minutes but users will only be down for a couple minutes while the original db is brought down and cloned and brought back up.

I have not done a lot with time finder yet. I'm assuming the clone will work better for this scenario than snaps or mirrors. I'm also assuming that the Veritas backup will take longer than 90 minutes (with the copy on access option) because data will be moved from the original stds to the clone stds as the clones are being accessed by netbackup.

Am I going down the right path or should I be doing something different? Not sure when I should use clones vs snaps vs mirrors.

6 Operator

 • 

2.8K Posts

March 13th, 2008 01:00

Brad I think that this thread is better hosted in the "Solution Enabler" or the "Open Systems" area of the forums". If you agree I'd ask admins to move the thread.

To save time I would like to shut down the database
then clone the database devices and then immediately
bring the progress database and application backup
after the clone. This should take about a minute
rather than 90 minutes.


You are right. You can issue "symclone create/recreate" while the database is still working and shut down the database only when you are ready for the "activate" command. Activating clones will take a very short time .. A minute or less. As you said, you can startup the DB right after the "activate".

Once I have mounted the clone file system I will back
it up with Veritas netbackup like before. This will
still take 90+ minutes but users will only be down
for a couple minutes while the original db is brought
down and cloned and brought back up.


I love it .. That's why we called it "TimeFinder" !! :D You gave a perfect description of what's going on !! :D

I have not done a lot with time finder yet. I'm
assuming the clone will work better for this scenario
than snaps or mirrors. I'm also assuming that the
Veritas backup will take longer than 90 minutes (with
the copy on access option) because data will be moved
from the original stds to the clone stds as the
clones are being accessed by netbackup.


You don't really need to use the good old "Copy on access" option. You can enable the "full copy" of your STD to TGT. And if you really want to use all available features, you can also use "differential" option that will copy only changed tracks from previous clone session.

That's what I'd do...

You have to setup at first your environment, issuing a full copy of your devices.

# symclone -dg AixDb_Dg -copy -differential create (add various parameters you may need)
# symclone -dg AixDb_Dg activate (add needed options)

... now sit and wait .. you are simply setting up the environment .. check when all the devices are in "copied" state with one the following command:

# symclone -dg AixDb_Dg -copied verify (maybe you require other parameters)
# symclone -dg AixDb_Dg query (again maybe you need more options here)

Now when all the devices have been fully copied use the following steps to backup your progress db.

1) symclone -dg AixDb_Dg -copy -differential recreate (add needed options)
2) shutdown_progress.sh
3) symclone -dg AixDb_Dg activate (add needed options)
4) startup_progress.sh

Now -again- sit and wait a little .. Give some time to the box so that the background copy process completes and then

5) mount clones on different host
6) backup your db with your favourite backup product
7) enjoy ;-)
8) don't forget to unmount the clones ASAP ...

Now you can choose if you want to recreate the clones at the very end of the backup procedure or at the very beginning .. Both ways will work (I choose to recreate them at the very beginning, see step 1) but another option you have is to leave the clones ready for the activation (in recreated state) all day long. I'd suggest keeping them active and recreating them when you start the backup procedure (as in my example) however you have options.

Just to explain what I mean when I write "(add needed options)" or similar sentences, you can use -consistent .. Or you can use -tgt option .. or supply the list of SRC and TGT ...

117 Posts

March 12th, 2008 17:00

There may be some religious disagreements on this, but here is my opinion.

Option 1. TimeFinder/Mirror. The advantage is that you can pre-sync the BCV's and split them as soon as the database is down. Once you split, you will have a completely independent image. The disadvantage is that you need additional disk space for BCV's - same logical size as your database volumes, but you can make them unprotected.

Option 2. TimeFinder/Clone. The only advantage is that there are very few restrictions on the target volume. You still need the disk space and EMC does not support unprotected non-BCV volumes. So, I would not even consider this option.

Option 3. TimeFinder/Snap. The advantage is that you don't need to have a lot of additional disk space. The disadvantages are performance on your source volume and you still need to create SAV devices to store any changes.

Personally, I would go with BCV's, unless disk space is really the issue.

2 Intern

 • 

1.3K Posts

March 12th, 2008 17:00

In our case 99% is option 1. In option 1 itself you can do twp ways and both can be done when the DB is up.

1.sync bcvs ,put db in hotbackup mode,TF/CG consistent split which would be easy recover
2. Just sync and do TF/CG consistent split

6 Operator

 • 

2.1K Posts

March 13th, 2008 04:00

First I wanted to comment on Stefano's mention of moving the thread. Personally I think it is in the perfect place since the question is more about the technology options available than the details of how to implement (what command line arguments, etc.). Just my opinion though...

Now, to the real question... I think the options have been laid out well already, but in our environment we found that for some of our apps it made more sense to use SNAPs of the prod data to mount for the backup process. This was done after a careful evaluation of the performance profile of the app. Fortunately during the period we run the backups our SAP environment (the first to go this way) is relatively "quiet". During the day we need the extra performance, but at night we can take the "hit" of running backups off a SNAP. If your application fits this model then there is no reason to "waste" the space required for BCV or Clone targets.

For this particular situation, if you were not going to use SNAPs, the question of Clone or BCV depends a lot on how you want to time your backup process. I'll start by saying that I don't think it makes sense to use BCVs just to save disk by not using protected volumes. If you are going to have a full copy of your database to use for backup you might as well count on it as your first line of defense for the restore process. If you needed to do a restore within 24 hours you could avoid tape by keeping the Clone or BCV copy ready to restore from first. In order to count on this (and on your backup to tape being successful) you need to have a reliable source (meaning a protected device).

So now it comes down to a simple question: Do you want to be able to back up the copy of your data immediately on bringing your database back online? Or can you afford to wait a while?

If you can wait I would recommend Stefano's approach with the Clones. Let the full copy complete before starting your backup. If you could afford the performance hit of not waiting you might as well save your Clone space and use SNAP. In the long run I feel it gives more flexibility and it is the eventual target state of the TimeFinder technology anyway.

If you can't wait to start you backup then you only really have the BCV option. Not a bad thing, but in my opinion not the best choice (unless all the answers to the questions asked drive you there... then it IS your best choice :-) )

Hope I'm not just muddying the waters *lol*

11 Legend

 • 

20.4K Posts

 • 

87.4K Points

March 13th, 2008 05:00

i like two different perspectives from Allen and Stefano. In one of my previous jobs we had an application that was residing on protected BCV and every night was restored to regular STD for reporting. Back in the days clones were not available and they could not wait for BCVs to finish syncing. Since STD were available immediately after issuing the restore command ..the option worked. Now we have clones and snaps ..so many options ..beautiful thing.

6 Operator

 • 

5.7K Posts

March 13th, 2008 05:00

So many options, so many licenses ;)

IMHO Clones would be the better choice over BCV, since
a) You need to mask the clone to a host for backup, so you would need a protected BCV anyway
b) You never exactly know when a BCV is done syncing before you can do the split and with Clones, when you activate it, it's ready for use
c) You don't need to worry about mirror positions with Clones as with BCV's you do
d) Clones are the new technology, thus better


... forget that last remark ;)

6 Operator

 • 

5.7K Posts

March 13th, 2008 06:00

OMG, there he is again: Del Corno, go stand in the corner !
;)

6 Operator

 • 

2.8K Posts

March 13th, 2008 06:00

many options = many licenses = more money for me ....

C'mon go out and buy all available licenses .. I'll get a better car !! ;-)

207 Posts

March 13th, 2008 16:00

Wow this is all excellent info. I use to hate Powerlink because I could never find anything - now that I have stumbled on to this fourm great!

Based on my situation I think I will follow Stephon's example because he has all the steps mapped out for me. I noticed that when I try to use the -differential or
-recreate options I get the following error - "The requested feature is not supported for this microcode or symapi version". I am running 6.4.2 and microcode 5670.

Anyway I was able to test almost everything out without those features and it all works very well. The database file system is mounted on three 16-way striped meta volumes and is around 270 GB total. The create takes about 40 seconds and the activate is almost immediate. At that point I can importvg and mount the cloned file system on the other host. Response time against the cloned DB is fine.

11 Legend

 • 

20.4K Posts

 • 

87.4K Points

March 13th, 2008 21:00

I noticed that when I try to use the
-differential or
-recreate options I get the following error - "The
requested feature is not supported for this microcode
or symapi version". I am running 6.4.2 and microcode
5670.


yep, have to have 71+ for -differential option

6 Operator

 • 

2.8K Posts

March 14th, 2008 01:00

I noticed that when I try to use the -differential or
-recreate options I get the following error - "The
requested feature is not supported for this microcode
or symapi version". I am running 6.4.2 and microcode
5670.


C'mon guy, be serious !! :D Ask EMC to upgrade your code .. :D

If you can, I think it's better if you ask your CE to upgrade the DMX to 5671.

However I'm happy that it worked :D

117 Posts

March 14th, 2008 06:00

At that point I can importvg and
mount the cloned file system on the other host.

I would strongly recommend to use recreatevg instead of importvg. You do have to specify all hdisks in a volume group for recreatevg, but the later will generate new PVID's. There are two advantages because of this: 1) you are no longer dependent on correct PVID's coming over from the source devices to the target ODM and 2) you are guaranteed to have unique PVID's in your environment, even if you later move the devices around.

207 Posts

March 14th, 2008 09:00

OK, good info about recreatevg. My thoughts were that if I needed to mount the file system to the same host that I would need to use recreatevg. I definitely don't want the same PVIDs on the same host.

Since I'm doing my importvg and mount on a different AIX host (connected to the same dmx) I thought the importvg would be correct.

2 Intern

 • 

1.3K Posts

March 14th, 2008 11:00

you are on the right track
No Events found!

Top