Forcing Full backups

[mricca]

Currently we only run progressive incrementals on all our server. Questions came up today in a meeting about running Full backups.
Per IBM, TSM's methodology is a progressive incremental one. However, honestly, how many of you out there force a full on all your systems? We did have a situation where we had to restore and OA server with millions of small files and it took a week. Honestly, will forcing a full drastically reduce this amount of time? If this is the case, why is TSM a progressive incremental backup method?

What does forcing a full backup really do?
Will it put all the current data you need to restore on one single tape

 

[heada]

A full will decrease restore time but only the closer you are to the time you did the full (the longer its been since the full, the longer it will take to perform the restore)

A better option is co-location. It will keep all the client's data (or group of clients) on the same tapes so that it keeps mounts to a minimum. There is also the option to tell TSM to search the MP queue to restores that are on tapes that are already mounted.

-Aaron

 

[mricca]

We already collocate all our tapes in the tapepool (onsite library tapes)Only offsite is non-collocated.

What about performing a move nodedata occationally. They are talking about maybe forcing Fulls every month on our Network servers. Like O/A which has millions and millions of files. The times they have done this before, it has filled up the TSM log file numerous times and took forever to run. Just makes me nervous because I continually have to q the log and run DB backups when it is running.

If I do a movenode data will that reduce the number of tapes the data is on. If we have servers that a full was done 5 years ago...

 

[penguinperk]

What is your concern? It almost sounds like it is about the amount of time that it will take to do a restore. I am not sure if you have the disk space available but I would recommend to do a test, a full volume restore.

 

[mricca]

My biggest concern is the amount of time it takes to do a restore on a network server that has over 8 million small kb files. Our network guys want to start forcing full backups on these servers...which already with just an incremental backup and journaling still take over 12 hours to run. Last time they forced a full I had to run like 4 DB backups just to keep the log file cleaned out.
I guess I am just looking for other options for staging a restore on these servers without having to force a monthly full. The data is already collocated.

 

[chad_small]

Don't do fulls, if they are windows machines do image backups . They are faster and don't adversely affect the TSM DB or Log. They also are the best route when systems get to 8+ million files. I recommend them whenever they are possible. If the systems are UNIX are the filesystems mirrored? If so you could split the mirrors then do an image backup.

 

[mricca]

The servers in question are Windows servers.
If you do an image backup, you can only restore that image correct? You cannot restore single files from it right?
How does DR work with image backups? Does it send a copy offsite and keep one onsite like all the other backups?
I have never performed and image backup nor restored one.
Would be nice if we had servers available to run tests on...but you know how that goes.
Can you image the entire server? For instance...you image the entire server on Monday and on Friday you lose your system. Once rebuilt you could apply the image and then individually restore files from the backups that took place from Monday on?
What is the difference between an image backup and a Ghost of the server? Other than TSM controls the image. Can you get the same results with both?

 

[lcaroca]

you can to do a selective backup.

 

[mricca]

But isnt a "selective" backup like forcing a "full" backup again? Not a progressive incremental, but an actual full like the first time it ever backed up. It backs up the files whether they are new or not. This totally slams my TSM DB and log files when they do it on a network server with million of files.

 

[alimirza]

As Chad suggested, image backups seems to be a solution to your problem. Since images on windows machines can be taken while the system is online i.e "Snapshot image backup" there is no down time involved. Image backups are helpfull in cases where you have to restore full system, a disk partition or your full drives c: or d:. So, for a DR its a good solution. You can keep doing you incrementals and when you need to restore a system, you just restore the image and then restore all the files that has been backed up through incrementals using "-fromdate -fromtime and -todate and -totime" parameters with the restore command.

So, on the weekend, lets say on Saturday you take image of the system and then the rest of the ween run regular incremental backups. Assuming that your system crashed or monday, you will restore the image from Saturday and the restore the incrementals from dailiy incrementals using the -fromdate and -fromtime options and only tapes that has backup of sunday and monday will be selected for restore. Also make sure that your collocation is done by FILESPACE and not by NODE and this will further help you.

To restore an image you need to boot the machine using WINPE (windows pre-installation) CD or bart PE CD. You can customize these CD and have TSM client on the CD itself. The restore is quick and you should be up and running quickly.

Archives in your situation is not an option as TSM database will grow rapidly because of the number of files you have.

hope this helps and YES image backups are similar to ghost

 

[chad_small]

TSM has a process to restore Images+incrementals in the client. As it says in the manual:

If you have run progressive incremental backups and image backups of your file system, you can perform an incremental image restore of the file system. The process restores individual files after the complete image is restored. The individual files restored are those backed up after the original image. Optionally, if files were deleted after the original backup, the incremental restore can delete those files from the base image. Incremental backups and restores can be performed only on mounted file systems, not on raw logical volumes.

You don't have to use the -fromdate/-todate options to execute the restore to a specific timeframe.

 

[PJ]

We keep our fileserver backups on disk (prog incr only). Full restores exceed our targeted performance of 150 GB/h.

PJ

 

[mricca]

PJ,
Thanks so much for the information. That is exactly what I was looking for. I will present this option to our Network guys who are in charge of TSM backups for these servers.

 

[yanez.kike]

Hi .. I'm newbie with TSM.. in my job they have already TSM 5.4 but we are goint to migrate to Version 6.1.. but they want to apply a model of doing 1 full backup every week and 1 incremental every day.. They want to do that because of this similar problem... because it take a lot of time to restore a server that has been for more than 3 years in TSM.. how could you solve this issue??

I have been reading about it .. and i can't find the reasons to avoid this new scheme (Full week + Incremental ) .. I will appreciate your help..

 

[Jeff_Jeske]

I think anyone with a file server has this problem. We aren't even that big of a shop and we have more than a handful of file servers with 10 million objects on them. All are protected via SAN replication however we have additional protection for a non-full-dr situation.

First thing is using a non-TSM approach to file restore. We have enabled shadow copies on the file server sized enough to retain about 5 days worth of change.

To reduce exposure we have set a limit to the size of a drive letter. Example don't let the E: drive get larger than 1TB. This is extended to share names. Don't let SHARE_FINANCE get bigger than 1TB.

We set a max object count of public share servers to 10 million objects. If a file server reaches 10 million objects we fan out to another server via DFS.

We send file server incremental backups to a file device class or CDL. It would be a nightmare to retrieve directly from tape. However we've had users scram entire folders that are multiple years old and even from disk these sometimes take longer than expected.

We have deployed image backups to enhance the recovery of a volume. Image backups are sent directly to tape because most volumes are sized about 1TB. These image backups are run once every month. They greatly reduce the amount of time it takes to recover a single volume. After the image is restored we then restore the incremental *** (this is done because the Tape TSM server is not the same instance as the file dev class TSM server) ***

This approach limits exposures during the most likely restore scenario as well as full DR.
However it will still require a near 24 hour recovery of single file server drive letter. A full server DR via TSM would also take multiple days to complete.

The current approach to file server exposures is data managment. We have a project to identify business critical data (BCD) and store that on a different file server away from all the "normal junk". Simply by moving the BCD to a different location you've probably added two or three levels of protection from stupid users tricks like accidental deletes or virus infections. Be a smaller subset of data it will also be faster to recover. It is a challenge to manage the BCD but it must be done.

 

[GregE]

If I were you I would discuss this with the people who want to do Full weekly + Incremental Daily and explain that this is not how TSM is designed. You could do it, but it would be messy to setup. Let TSM do its progressive incremental and setup collocation on the storage pools that require it.