VeritasNetBackup: Restores from multiplexed database backups
NetBackup can run several restores at the same time from a single multiplexed tape. This is done by means of the
MPX_RESTORE_DELAY option, which specifies how long, in seconds, the server waits for additional restore requests of files or raw partitions that are in a set of multiplexed images on the same tape. The restore requests received within this period are executed simultaneously. By default, the delay is 30 seconds.
This may be a useful parameter to change if multiple stripes from a large database backup are multiplexed together on the same tape. If the MPX_RESTORE_DELAY option is changed, you do not need to stop and restart the NetBackup processes for the change to take effect.
When bprd, the request daemon on the master server, receives the first stream of a multiplexed restore request, it triggers the MPX_RESTORE_DELAY timer to start counting the configured amount of time. At this point, bprd watches and waits for rela ted multiplexed jobs from the same client before starting the overall job. If another associated
stream is received within the timeout period, it is added to the total job, and the timer is reset to the MPX_RESTORE_DELAY period. Once the timeout has been reached without an additional stream being received by bprd, the timeout window closes, all associated restore requests are sent to bptm, and a tape is mounted. If any associated restore requests are received after this event, they are queued to wait until the tape that is now “In Use” is returned to an idle state.
If MPX_RESTORE_DELAY is not set high enough, NetBackup may need to mount and read the same tape multiple times to collect all of the necessary header informa tion necessary for the restore. Ideally, NetBackup would read a multiplexed tape, collecting all of the header information it needs, with a single pass of the tape, thus minimizing the amount of time to restore.
Example (Oracle):
Suppose that MPX_RESTORE_DELAY is not set in the bp.conf file, so its value is the default of 30 seconds. Suppose also that you initiate a restore from an Oracle RMAN backup that was backed up using 4 channels or 4 streams, and you use the same number of channels to restore.
RMAN passes NetBackup a specific data request, telling NetBackup what information it needs to start and complete the restore. The first request is passed and received by NetBackup in 29 seconds, causing the MPX_RESTORE_DELAY timer to be reset. The next request is passed and received by NetBackup in 22 seconds, so again the timer is reset. The third request is received 25 seconds later, resetting the timer a third time, but the fourth request is received 31 seconds after the third. Since the fourth request was not received within the restore delay interval, NetBackup only starts three of the four restores. Instead of reading from the tape once, NetBackup queues the fourth restore request until the previous three requests are completed. Since all of the multiplexed images are on the same tape, NetBackup mounts, rewinds, and reads the entire tape again to collect the multiplexed images for the fourth restore request.
Note that in addition to NetBackup's reading the tape twice, RMAN waits to receive all the necessary header information before it begins the restore.
If MPX_RESTORE_DELAY had been larger than 30 seconds, NetBackup would have received all four restore requests within the restore delay windows and collected all the necessary header information with one pass of the tape. Oracle would have started the restore after this one tape pass, improving the restore performance significantly.
MPX_RESTORE_DELAY needs to be set with caution, because it can decrease performance if its value is set too high. Suppose, for instance, that the MPX_RESTORE_DELAY is set to 1800 seconds. When the final associated restore request arrives, NetBackup resets the request delay timer as it did with the previous requests.
NetBackup then must wait for the entire 1800-second interval before it can start the restore.
Therefore, try to set the value of MPX_RESTORE_DELAY so it is neither too high or too low.
NetBackup storage device performance
This section looks at storage device functionality in the NetBackup data tra nsfer path.
Changes in these areas may improve NetBackup performance.
Tape drive wear and tear is much less, and efficiency is greater, if the data stream matches the tape drive capacity and is sustained. Generally speaking, most tape drives have much slower throughput than disk drives. Match the number of drives and the throughput per drive to the speed of the SCSI/FC connection, and/or follow the hardware vendors’
recommendations.
These are some of the factors which affect tape drives:
Media Positioning
When a backup or restore is performed, the storage device must position the tape so that the da ta is over the read/write head. Depending on the location of the data and the overall performance of the media device, this can take a significant amount of time. When you conduct performance analysis with media containing multiple images, it is important to account for the time lag that occurs before the data transfer starts.
Tape Streaming
If a tape device is being used at its most efficient speed, it is said to be streaming the data onto the tap e. Generally speaking, if a tape device is streaming, there will be little physical stopping and starting of the media. Instead the media will be constantly spinning within the tape drive. If the tape device is not being used at its most efficient speed, it may continually start and stop the media from spinning. This behavior is the opposite of tape
streaming and usually results in a poor data throughput rate.
Data Compression
Most tape devices support some form of data compression within the tape device itself.
Compressible data (such as text files) yields a higher data throughput rate than non-compressible data, if the tape device supports hardware data compression.
Tape devices typically come with two performance rates: maximum throughput and nominal throughput. Maximum throughput is based on how fast compressible data can be written to the tape drive when hardware compression is enabled in the drive. Nominal throughput refers to rates achievable with non-compressible data.
Note Tape drive data compression cannot be set by NetBackup. Follow the instructions provided with your OS and tape drive to be sure data compression is set correctly.
In general, tape drive da ta compression is preferable to client (software) compression such as that available in NetBa ckup. Client compression may be desirable in some cases, such as for reducing the amount of data transmitted across the network for a remote client backup.
Multiplexing and multi-streaming.
Consider the following factors regarding multiplexing and multi-streaming.
When to use multiplexing and multi-streamingultiple data streams can reduce the time for large backups. The reduction is achieved by splitting the data to be backed up into multiple streams and then using multiplexing,
multiple drives, or a combination of the two for processing the streams concurrently. In addition, configuring the backup so each physical device on the client is backed up by a separate data stream that runs concurrently with streams from other devices can significantly reduce backup times.
Note For best performance, use only one data stream to back up each physical device on the client. Running multiple concurrent streams from a single physical device can adversely affect the time to back up that device because the drive heads must move back and forth between tracks containing the files for the respective streams.
Multiplexing is not recommended for database backups, when restore speed is of paramount interest, or when your tape drives are slow.
Backing up across a network, unless the network bandwidth is very broad, can nullify the ability to stream. Typically, a single client can send enough data to saturate a single 100BaseT network connection. A gigabit network has the capacity to support network streaming for some clients. Keep in mind that multiple streams use more of the client’s resources than a single stream. We recommend testing to make sure that the client can handle the multiple data streams and that the users are not affected by the high rate of
data transfer.
Multiplexing and multi-streaming can be powerful tools to ensure that all tape drives are streaming. With NetBackup, both can be used at the same time. It is important to distinguish between the two concepts:
Expect the duplication of a multiplexed tape to take a longer period of time if it is demultiplexed, because multiple read passes of the source tape must be made.
When you duplicate a multiplexed backup , demultiplex it.
By demultiplexing the backups when they are duplicated, the time for recovery is
significantly reduced.
Do not use multi-streaming on single mount points. Multi-streaming takes advantage of the ability to stream data from several devices at once. This permits backups to take advantage of Read Ahead on a spindle or set of spindles in RAID environments.
Multi-streaming from a single mount point encourages head thrashing and may result in degraded performance. Only conduct multistreamed backups against single mount points if they are mirrored (RAID 0). However, this also is likely to result in degraded performance.
Effects of multiple data streams on backup/restore
Multiplexing
To use multiplexing effectively, you must understand the implications of multiplexing on restore times. Multiplexing may decrease overall backup time when you are backing up large numbers of clients over slow networks, but it does so at the cost of recovery time. Restores from multiplexed tapes must pass over all nonapplicable data.
This action increases restore times. When recovery is required, demultiplexing causes delays in the restore process. This is because NetBackup must do more tape searching to accomplish the restore.
Restores should be tested, before the need to do a restore arises, to determine the impact of multiplexing on restore performance.
When you initially set up a new environment, keep the multiplexing factor low.
Typically, a multiplexing factor of four or less does not highly impact the speed of restores, depending on the type of drive and the type of system. If the backups do not finish within their assigned window, multiplexing can be increased to meet the window. However, increasing the multiplexing factor provides diminishing returns as the number of multiplexing clients increases. The optimum multiplexing factor is the number of clients needed to keep the buffers full for a single tape drive.
Set the multiplexing factor to four and do not multistream. Run benchmarks in this environment. Then, if needed, you can begin to change the values involved until both the backup and restore window parameters are met.
Read more Veritas NetBackup, Backup Planning and Configuration Guidelines
& Veritas NetBackup, Encryption, Java and Configuration Hardware
Latest Posts
-
05/05 – Ubuntu's OpenGL Face Browser with GNOME Desktop Manager
-
25/04 – Veritas NetBackup: Dedicated or Shared Backup Environment
-
16/04 – Dvd+rw-tools makes it possible to burn Dvd images created by “dvdauthot” or “mkisofs”
-
15/04 – FEBE (Firefox Environment Backup Extension) 5.3.1 released
-
14/04 – Veritas NetBackup, Backup Planning and Configuration Guidelines
-
13/04 – Ubuntu Server Guide, Part 3: PostFix, PostgreSQL, Databases and SMTP Authentication
-
10/04 – New Compiz Fusion: Cubereflex rename to Cubeaddon with new effect Cylinder
-
08/04 – RSS Buttons Collection Pack for Your Blog: The Ultimate List
-
05/04 – MP3Roaster is a Perl hack for Burning Audio Cds out of Mp3 OGG Vorbis and FLAC files
Linux Links
-
17/05 – Super Grus is a Bootable Floppy or CDRom that is oriented towards system record
-
13/05 – Knoppix 5.0: Using NDISWrapper to install Driver on Linux
-
10/05 – BRU, Server for Linux a native Linux Backup Software Solution
-
08/05 – CdBackup, Utility Designed to Work with any Backup and Restore for Linux
-
08/05 – Ubuntu 8.04 Hardy Heron and Ubuntu 8.10 Intrepid Ibex: New Graphic Tools
-
05/05 – GNU Cpio Copies Files into or out of a Cpio or tar Archive
-
04/05 – Simple Linux Backup is a easy-to-use backup to automatically backup a Linux Desktop System
-
03/05 – DIBS is a Backup System that Protects your Data by Giving your Files to Peer
-
02/05 – Updates Medibuntu Repostories for Ubuntu 8.04 Hardy Heron
-
30/04 – Enigmail, extension to the Mail Client of Mozilla Thunderbird and Mozilla SeaMonkey
-
24/04 – Timidity ++ is an Open Source MIDI to WAVE converter and player
-
23/04 – Ubuntu Start Manager for the bootloader (Grub o Grub2) and boot splash (Usplash or Splashy)
-
23/04 – Gvtray for Xubuntu, a voume control for four system tray
-
22/04 – a MSN is a Windows Live Messenger clone licensed under the GPL
-
20/04 – VLC VideoLan Media Player 0.86 f release for Ubuntu Linux




digg it
del.icio.us










