Upload
alma-ames
View
222
Download
2
Embed Size (px)
Citation preview
IBM Tivoli User Groups
© 2004 IBM Corporation
Best Practices for Backing Up Windows Servers Using IBM Tivoli Storage Manager
Dave Daun [email protected]
Tivoli User Groups
© 2004 IBM Corporation
Abstract
This session will focus on various best practices surrounding the configuration of TSM to protect Windows. Features of the TSM client that are specific to Windows such as Journal Based Backup, System Objects, Open File Support, ASR, and Image Based Backup will be included. Some typical pitfalls of backing up and restoring Windows will be presented and recommendations will be made on how they can be avoided.
Windows Best Practices
Tivoli User Groups
© 2004 IBM Corporation
Agenda
What’s unique about Windows?
Windows only features of TSM.
General TSM features important for Windows.
Putting it all together – Best Practices for Backup and Restore.
Tivoli User Groups
© 2004 IBM Corporation
What’s Unique About Windows?
Tivoli User Groups
© 2004 IBM Corporation
Backing up Windows – Unique Problems
Registry, Active Directory, and other system objects
Plug and Play
Typical to have many servers with unique configurations
Typical to have lots and lots of directories with wide and deep structures
Lots of small files are very common. Sometimes they make up LARGE AMOUNTS OF DATA!
Tivoli User Groups
© 2004 IBM Corporation
Windows-Only Features of TSM
Tivoli User Groups
© 2004 IBM Corporation
System Objects
Prior to version 5.1, Windows system object files could be backed up incrementally when backing up the system object.
In version 5.1 and above, a full copy of all Windows system object files is taken during each backup. A full set of these objects is kept for each version of the system object that is retained based on policy.
There are many (usually over 2000) TSM objects (e.g. files) associated with the Windows system object.
Typical system object backup for a server can be 400 Mb or greater.
Tivoli User Groups
© 2004 IBM Corporation
System Objects (continued)
Large numbers of Windows systems with longer retention policies can produce large amounts of data! 500 “small” Windows Boxes
30 version retention
DB Sizeo 500 * 1 * 2000 * 600 = .6 GB (first object)o 500 * 29 * 2000 * 600 = 17.4 GB (additional copy)o 500 * 30 * 2000 * 200 = 6.4 GB (copy storage pool)o Total DB = 29.4 GB
Nightly Datao 500 * 400 Mb = 200 GB
Tivoli User Groups
© 2004 IBM Corporation
System Object Recommendations
You can use an include statement to assign the Windows system object to a different management class that causes them to be kept for a shorter period of time.Ex. include.systemobject sysobjclass
include.systemstate sysstateclass
Carefully consider how system objects will be used. If you intend to rebuild a box for scratch in the event of its total loss, use the domain statement to exclude system objects.Ex. domain all-local –systemobject
Tivoli User Groups
© 2004 IBM Corporation
Tivoli Storage Manager’s Bare Machine Recovery
Ensure business continuanceEnsure business continuance
Reduce administrative costsReduce administrative costs
Maximize current hardware Maximize current hardware investmentinvestment
Brings back system to state of last backup Recovers all the OS changes and customizations
Streamlines and automates the OS recovery process
Eliminates the need for highly skilled professionals to manually reinstall hardware, network, patches…
Speeds up the recovery time
Integrates bare machine backups directly to Tivoli Storage Manager server
Cristie Bare Machine Recovery V4.10
Tivoli Storage Manager's V5.2
ASR
Tivoli Storage Manager for
System Backup and
RecoveryAIX 4.3.X, 5.1, 5.2 YESWindows NT YES Windows 2000 YES Windows XP YES YES Windows 2003 YES YES Sun YESLinux YESHP CU2005
Tivoli User Groups
© 2004 IBM Corporation
BMR (Bare Machine Recovery)
Prior to Windows XP and 2003, a 3rd party product was required to do automated Bare Machine Recovery.
Windows XP and 2003 introduced a semi-automated solution for BMR called Automated System Recovery (ASR).Provides for restore in the event of a catastrophic system or
hardware failure
Goal is to return the operating system to the point of last backup – not for restore of application or user data
Invokes the new Windows API calls
Restores the operating system files and system state data
Tivoli User Groups
© 2004 IBM Corporation
ASR Restore Overview
Insert the Windows installation CD into the CD-ROM drive
Restart the system and boot from CD You may need to do some BIOS configuration
Press F2 to enter ASR recovery mode
Insert the TSM-created ASR diskette (label TSMASR) into the floppy drive Windows will read the diskette and then reformat the boot partition and possibly
other partitions
Windows will copy installation files to the hard drive
Insert the TSM client installation package CD (labeled TSMCLI) into the CD-ROM drive The TSM client installation package will be copied to the hard disk
Insert the ASR diskette into the floppy drive (if not already there) Windows copies TSM files from the diskette
Tivoli User Groups
© 2004 IBM Corporation
ASR Restore Overview (cont)
Remove the diskette and the system reboots
Insert the Windows install CD into the CD-ROM drive
After the Windows setup completes, two command windows are opened One runs the TSM client silent install
One is available for diagnostic purposes
You will be prompted to choose either network connected restore from the TSM server or local backupset restore
Restore from TSM server requires node name and password
Restore from backupset requires the path and name of the local backupset – you will be prompted when subsequent volumes are needed
TSM restores the system state or system objects
TSM restores the system drive (partition)
Tivoli User Groups
© 2004 IBM Corporation
ASR Overview (cont)
Remove the TSMASR diskette and the machine reboots
The operating system comes up in fully recovered state
Restore user data and applications
Use traditional TSM restore facilities
Address and “application specific” recovery issues
Tivoli User Groups
© 2004 IBM Corporation
ASR Pros and Cons
ProsProvides a Microsoft / Tivoli supported methodology for doing a
Bare Machine Recovery
ConsLots of Prerequisites
o Same / Similar Hardwareo Certain Disk Geometries / Sector Sizes
Only works from a floppy drive (no support for network boot)
Still a “guided process”
Still need to plan for “application recovery”
Tivoli User Groups
© 2004 IBM Corporation
JBB (Journal Based Backup)
Journal Based Backup allows an incremental backup to occur using a local database called a change journal. The local database is used to determine what has changed and needs to be backed up.
Windows clusters are supported beginning at version 5.1.6.
Can significantly reduce backup time for file systems with large numbers of files of which a small number change. Typical Windows File Server
Recommended for systems with large numbers of files where the amount of files that change is less than 10-15% of the total.
Tivoli User Groups
© 2004 IBM Corporation
Image / Snapshot Backup Image / Snapshot Backup allows you to do a block level backup of a
Windows system.
Pros of Image Backup Much (orders of magnitude) faster than file-by-file when doing a full
volume restore. Snapshot technology can be used to back up open files Can be combined in a rotation w/ normal incremental backups to achieve
a “point in time” restore. Requires only one entry in the TSM database.
Cons of Image Backup Requires a separate drive from the one being backed up for the snapshot
image. Can use more network bandwidth when using LAN based backup
(because you need to move the entire volume). Cannot be used to restore a single file; must restore the entire volume.
Tivoli User Groups
© 2004 IBM Corporation
OFS (Open File Support)
TSM version 5.2 allows for backing up of open files on Windows 2000 (not supported yet on Windows 2003).
Leverages the TSM Logical Volume Snapshot Agent used for image backup.
Recommend for use with applications that do not support backup through other APIs (e.g. MS Access).
Tivoli User Groups
© 2004 IBM Corporation
Image and OFS Options SNAPSHOTCACHELOCATION
Controls the location of the OBF (old blocks file) during image backup.
SNAPSHOTFSIDLEWAIT
Time which can pass waiting the disk to have no write activity so the snapshot can be taken.
SNAPSHOTIDLERETRIES
Number of times the LVSA should try to achieve the snapshot.
INCLUDE.FS
Can be used to exclude a volume from LVSA processing.
“include.fs C: fileleveltype=dynamic”
PRESNAPSHOTCMD and POSTSNAPSHOTCMD
Can be used to quiesce applications before and after a snapshot.
Tivoli User Groups
© 2004 IBM Corporation
Image and OFS Caveats
The LVSA is not intended to provide Windows system backup.This is done through the system object and system state.
The snapshot cache file cannot be located on the drive being backed up.
The restore of an image backup cannot be done to the same drive as the TSM client is installed on.
Essentially, all this adds up to eliminate “single-drive” systems.
Tivoli User Groups
© 2004 IBM Corporation
General TSM Features Important for Windows
Tivoli User Groups
© 2004 IBM Corporation
Volume Fragmentation
Large Windows file servers are particularly vulnerable to volume fragmentation when using incremental-forever backup methodology. Typically they have large numbers of small files and wide directory structures.
I have seen active files for a Windows system spread out over more than 250 tapes!
Active
Inactive
ExpiredTim
e
System A and B System A and B
Tivoli User Groups
© 2004 IBM Corporation
How Fragmented Is My Data? For a given node, the following SQL statement will show the all the volumes
used by active files. select node_name,filespace_name,stgpool_name,volume_name from volumeusage
where node_name=‘MYNODE' and node_name in (select node_name from backups where state='ACTIVE_VERSION' group by node_name)
NODE_NAME FILESPACE_NAME STGPOOL_NAME VOLUME_NAME ------------------ ------------------ ------------------ ----------------SSPERRY ASR SUNCPOOL IOX873 SSPERRY ASR SUNCPOOL IOX921 SSPERRY ASR SUNPOOL IOX872 SSPERRY ASR SUNPOOL IOX947 SSPERRY SYSTEM OBJECT SUNCPOOL IOX921 SSPERRY SYSTEM OBJECT SUNPOOL IOX947 SSPERRY \\ibmt40\c$ SUNCPOOL IOX866 SSPERRY \\ibmt40\c$ SUNCPOOL IOX873 SSPERRY \\ibmt40\c$ SUNCPOOL IOX904 SSPERRY \\ibmt40\c$ SUNCPOOL IOX912 SSPERRY \\ibmt40\c$ SUNCPOOL IOX921 SSPERRY \\ibmt40\c$ SUNPOOL IOX852 SSPERRY \\ibmt40\c$ SUNPOOL IOX863 SSPERRY \\ibmt40\c$ SUNPOOL IOX872 SSPERRY \\ibmt40\c$ SUNPOOL IOX900 SSPERRY \\ibmt40\c$ SUNPOOL IOX947
Tivoli User Groups
© 2004 IBM Corporation
Collocation Collocation is the classic solution for volume fragmentation
Segregates data from different sources
Can be done by node or by file space
Current level of granularity is by storage pool
Collocation can be thought of as a methodology for moving tape mounts from the restore to backup (during migration)
Pros of collocation
Collocation will significantly reduce restore time for systems that are prone to fragmentation (small files, large amounts of data)
Cons of collocation
Collocation will waste tape space (particularly with small systems and large sequential volumes)
Collocation will increase the library slot count necessary to keep all volumes in the library
Tivoli User Groups
© 2004 IBM Corporation
Multisession Restores
Restore uses multiple client-server sessions for a single file space.
New to version 5.1. Prior to version 5.1, only a single tape drive could be applied to a volume restore at a time.
Limited by Number of sequential-access volumes with data to be restored plus one
session for random-access disk Mount points on the client (as defined on the TSM server) Client's resourceutilization option
Works only for no-query restore (unrestricted wildcard) I often see 10x improvement in restore speed when using multisession!
Client Server
Session 2
Session 3
Storage pool
volumes
Session 1
Tivoli User Groups
© 2004 IBM Corporation
Full Backups
Periodic Full Backup
Although most people use the Incremental Forever methodology, TSM will allow you to do a full file-level backup
Set copymode to absolute on the copy group
Do a selective backup on the drive
Prepares for rapid client restore by Consolidating most recent copy of node data (reducing volume
fragmentation)
Significantly increases network utilization
Can be done periodically depending on levels of fragmentation
ALL Files for node BOB
Tivoli User Groups
© 2004 IBM Corporation
Move Nodedata Command
move nodedata bobfromstgpool=tapepool
ConsolidationFiles for node BOB
Movement to Disk
Files for node BOB
Moves files for specified node, file space, and data type residing in a specified sequential-access storage pool
Prepares for rapid client restore by Consolidating node data within a sequential-access pool Moving data to disk for fast access
Reconstruction option removes unused space within aggregates
Requires lead time before restore for disk, but can be scheduled for tape
move nodedata bobfromstgpool=tapepooltostgpool=diskpool
Tivoli User Groups
© 2004 IBM Corporation
Classic Restore vs. No-Query Restore
Classic restore processing1.Client queries server for information about files to be restored
2.Server sends file information to client
3.Client sorts files by storage location
4.Client sends restore request for each file in optimal restore order
5.Server sends each specified file to client
No-query restore (NQR) processing1.Client sends restore specification to server
2.Server sends matching files to client
Tivoli User Groups
© 2004 IBM Corporation
Classic Restore vs. No-Query Restore
Classic vs. NQR tradeoffs NQR reduces client-server interaction and client memory requirement NQR allows multi-session restores, but classic restore does not NQR is usually faster for restoring entire file systems or large directories Classic restore may be faster for restoring directories if data is highly
fragmented across sequential volumes with only a small amount of data on each volume
NQR is automatically used if both of the following apply The file specification is an unrestricted wildcard (/home/mydata/*)
None of the following are used: inactive, latest, pick, fromdate, todate
To force classic restore, use ?* in the file specification (home/mydata/?*) or use TESTFLAG DISABLENQR
Tivoli User Groups
© 2004 IBM Corporation
Putting It All Together – Best Practices for Windows Backup
and Restore
Tivoli User Groups
© 2004 IBM Corporation
Best Practices for Windows Backup Large clients with small files should be backed up to collocated
sequential access storage pools where feasible.
It will probably not be feasible to collocate all Windows clients, so consider segregating out the largest ones with the most files into a collocated storage pool.
Carefully consider how you will use system objects. Consider keeping only a small number of system object backups.
For large systems with multiple drives, consider doing regular image (or full) backups.
Consider using Journal Based Backup for very large systems with lots of file and relatively little change.
Consider using OFS on large Windows servers with multiple drives.
Tivoli User Groups
© 2004 IBM Corporation
Best Practices for Windows Restore Take advantage of Multisession Restore for Windows systems!
Resourceutilization = 6-10 and Max Number of Mountpoints = 3-4.
Monitor volume fragmentation for at risk systems. Take action to correct excessive fragmentation (e.g. move nodedata) before it’s too late.
Make sure you use No-Query Restore if you need to restore the whole file system.
If an image backup is available, restore the image and then apply the incremental in full restore situations.
If you are using Windows 2003 or XP, take advantage of ASR.
Document and test restore procedures. Particularly, be aware of “application recovery issues”.
Tivoli User Groups
© 2004 IBM Corporation
Questions or Comments?