Backup Strategies

All,

We are struggling with a backup strategy. We are using iwfreeze right now, but we find it to be flaky. There are a few things I would like clarified:

When the stores are frozen, and a backup is initiated, are files that are opened or locked backed up? What are the limitations.

Our Plan B involves stopping the TeamSite service (iwserver) and then doing a backup, followed by a reboot. Does this make sense?

Any thoughts here would be well received.

Regards,

Lucas Cochrane

Lucas Cochrane
lcochrane@dc.com

Find more posts tagged with

Comments

13adam13

Files that are opened can be backed up, if your backup software supports it. When you do the freeze, make sure that you are allowing enough time for the server to apply pending changes and you should not have any open files. Also, there is an article here about what files you can ignore when you back up.
Files That Can Be Ignored during a Backing Store Back-up

I assume that you are on a windows machine. This being said, it might be a good idea to go with Plan B anyway, since windows is very greatfull when rebooted.

--Adam Wilson
Senior Programmer

Migrateduser

To give the most useful answer, it would be helpful to know a few more things:

1) what hardware/OS platforms hosts your TS server?
2) what hardware/OS platforms hosts your TS backing store?
3) what bandwidth is available between server & store?

Without knowing those items I can describe a very successful backup strategy that I've implemented. You may not benefit from it as much w/out using some of the same hardware, but perhaps you can use some of the principles.

Our server is at a remote site and I wanted to ensure off-site backups (I _always_ want off-site backups for product source code). The backing store was resident on a Network Appliance fileserver. So I'd have TS freeze the backing store; delete the old backup snapshot; create a new snapshot. unfreeze the backing store. Voila, an on-site backup has been made; total time frozen <1min. Then the backup script would create a multi-volume tar on a fileserver at HQ during low activity times of the day. Later we got a tape drive at the remote site and a schedule for archiving the tape at HQ.

A critical part of a backup regimen is testing that your backups can actually be restored. It turns out that this can be accomplished very readily w/TS. The location of the backing store can be redefined in the configuration files. So we could do a distinctive submit (so we could tell for sure if we were seeing the restore or the original backing store); restore the backup to a different location; point the server to the restored backing store; test function and make sure the distinctive submit was _not_ present. If we were looking at the restore, and everything worked, we had a good backup. This testing should be done about once a month.

Gregg Faus

We've had good success in freezing the backing store and then copying it somewhere else to be backed up. Since the backup time is fairly long, this was the optimal solution. No need to freeze it longer then it takes to copy the backing store somewhere else.

We also tried "CA Backup Agent for Open Files". But that choked and never seem to work correctly. Plus our back jobs are done on multiple servers so the timing is not consistent from day to day since our TeamSite server is near the end of the job.