Minimizing system downtime for the full backup

[Mihails Nikitins]

I have a system storing a large amount of data and having DDS drive. Full offline backup takes several hours and occupies several tapes. I'd like to minimize downtime with my existing hardware and standard software.

I consider an idea of making backup of single partitions to a hard disk, and then
writing the files to tapes when the system is on-line. I guess "fbackup" and "dd" commands can be used for this purpose.

Thank you in advance for any comments!

[Devbinder Singh Marway · Accepted solution]

The following method will mean a little bit of down time ie.

why don't you split the file system / raw logical volume ( before you do this you need to stop the application) and then restart it

backup the data using ( dump for hfs file system) or vxdump for vxfs )

and then re-merge the split filesystems/Raw
volumes .

[Bruce Laughlin]

Hi Mihails,

Without doing anything else, you can reduce the time to do a backup with fbackup by half by making the following modifications:

1) If it doesn't already exist, create file /etc/sam/br/fbackup_config
2) In this file, make sure the following parameters have the following values:
blocksperrecord 128
checkpointfreq 256
(the defaults were 32 and 32)
3) If you use SAM to do your backups, it should use this file automatically. If you use fbackup from the command line, be sure to use the -c option, and specify the full path to fbackup_config.

Cheers,
Bruce Laughlin

[Irine Gibilisco]

Are you backing up a database? Assuming that you are, try putting your database into archive mode for the duration of the backup. If this is an Oracle database, it also has a "backup" mode, where any updates during a backup are written to a different archive files (which you will back up after you take the database out of backup mode). Get information on HOT BACKUPS in your database's manuals. Also try using "cpio" or "tar" in place of fbackup. CPIO will allow you to concatenate to the same tape, so that both your main backup and the following archive files are on the same media. With certain tape drives cpio and tar are also often much faster, as they take advantage of data compression. The command example "find -print | cpio -ocVbumd > /dev/rmt/0mn". Note, restoring will most likely be more cumbersome than with fbackup, but if this is a database, chances are you would need the entire thing, and in that case, the restore will be "cpio -icvBumdR < /dev/rmt/0mn". Don't forget to rewind the tape with "mt -t /dev/rmt/0m rew"

[John Palmer]

Well if you've got enough spare diskspace to hold a copy of you existing data then you have a couple of options:-

- Purchase MirrorDisk/UX if you don't have it already, mirror your data volumes then use lvsplit/lvmerge as suggested by Devbinder above to split off a copy which can be backed up at your leisure.

- Create a large enough filesystem on your spare diskspace then use a standard backup utility such as dump or vxdump to backup your required filesystems to this. Personally, I never use fbackup but you could probably use it as well. I would only use dd to copy raw volumes. You can backup this filesystem to tape later.

[James R. Ferguson]

Hi:

1. If you mirror your disk's file systems you could lvsplit your mirror, do a static backup, and lvmerge the mirrors.

2. If an Oracle database is involved, consider doing hot backups (of the database).

3. If you have Online JFS, consider doing a snapshot backup (see document #HPUXKBRC00001372 for more details).

...JRF...

[Fred Martin_1]

I have a similar problem. To reduce the size of backups, I do the following:

1. Once a week, backup any file unmodified for 6 months or more ("old" files). Exclude these files from all further backups. This is done during the day.

2. Off hours, daily, backup the remainder - however:

Monday back up file system A in full
and B,C,D get incrementals (only backup
the files modified since the last full
backup for that particular system.

Tuesday back up file system B in full
and A,C,D get incrementals....

Wednesday backup file system C in full
and A,B,D get incrementals....

And so on.

Restoring properly takes some head-scratching as you need to restore from more than one tape to get a full restore of any one file system. But it reduces tape space, and therefore backup time.

Fred

[Murray Jones]

The main issue with any backup solution is whether it will satisfy your restoration requirements. It is not much use taking measures to reduce backup times or introducing complexities into the backup solution if you cannot restore in the manner you require. As you can see from most of the replies, any major improvement may requre additional outlay for licenses etc (except for modifying blocking factors etc for fbackup - which as suggested, can make a good difference for both backup and restores).

My suggestion would be that if you are utilising multiple backup tapes as you indicate, that DDS may no longer be a suitable backup option for you - unless of course you might consider getting additional units etc (make sure you consider the seperation of I/O paths etc.) Otherwise, take a good look at what you really need to backup / restore. Do you need to back up all of your system areas daily? Perhaps you can back these up once a week? Depending on the environment, (production v dev) you may be able to do hot backups of databases and ensure that you have a good strategy for moving DB logs to tape instead.

Whatever you decide, make sure that is supported by good process and procedures.

Cheers,

[Carlos Fernandez Riera]

A view from DDS side:

- Am i reciving data as fast as i like?
- Is the compresion rate good or am i writting uncompressed?

- Are tapes adecuated to drive?
- Are tapes in good status?


Compile the attached file and run it after each backup command. This file is full statistics from drive and tape.

usage is dat3 /dev/rmt/xmn > res_x

[Carlos Fernandez Riera]

The attached file.

If not here it is in

http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0x979ee8644a22d411ade70090279cd0f9,00.html

[Mihails Nikitins]

Thanks to all of you!!!

I will consider splitting mirrors and better information selection policies. On the other hand, I believe that disconnected mirrors are in less consistent state than a stopped system. The worst thing is using of recovered files that were backed up in different times.