Hi Miles, MP>Hi Steve,
MP>interesting situation, have you considered, I'm sure you have, but: MP>- do you really need a point in time, why not just try and back it up, say 3 times, and on the last try just MP>back it up? ie. shared dynamic. There should be no downtime at all. Do the files change that fast? Is the shop MP>truly 24 x 7? There no time during the 24 hour day in which you can just run a back up? What would happen if MP>you couldn't restore a file? I've described the situation in more detail later in the email, but we can't do the backup during the day. If I can't restore a file on demand, my boss jumps on me from a great height. Then his boss jumps on top of him, whilst he is still thumping me. Then her boss jumps on her, to join in the melee and hit me with a length of pipe... In short, not pretty... And this is before the client finds out... ;) MP>This of course won't work if you absolutely can't have them changing and must back up a good copy. We really need to have all the services shut down on the boxes in question to get a consistent state on the disk (database files are just one of the issues). If we had the time, we'd dump the whole machine to tape whilst the services are down. However, the window is too small for this, so the only way to backup the consistent filesystem state is to break off the mirror, restart the services, back up the "faked" filesystems and re-sync the mirrors when the backup finishes. MP>Things I might try: MP>- run more than one backup per day. In several of my boxes I run a 'nightly' and a 'mid day' backup. MP>- have you tested backing up this filesystem, to see how many files don't get backed up because they are open MP>or changing? I don't have the TSM software or a server yet, so I'm not really in the position where I can judge the likely size of the daily incrementals. I suspect that the number of new files on each machine is relatively small. Similarly, I cannot say how many files would be open if a backup was performed at a given time. The purpose of shutting down the services prior to the backup is to stop new files transiting the machines, and ensure databases and other services are shutdown. MP>Forgive my skepticism, but it seems that things are more complicated than they need to be or I'm lucky to have MP>a couple of hours to run the backups. Even with this, I never worry about a couple of files not be backed up - MP>granted it is usually some perpetual log file. The situation is only made complicated by the situation I am inheriting. The existing backup infrastructure has evolved to the point where the client knows what it does, and it would probably be hard to convince them that they need to do something else. The client has a definite requirement to have the machines up 23x7, which is not negotiable. Because of the way the services interact, the machines *all* have to be down in the same window. I am firmly in your camp though! Least surprise is the best way to go. IF I can get every machine backed up in this window (which clearly depends on the network bandwidth at hand), then there is not an issue. Outside the backup window, the services *must* be up and the machines *must* be accessible. You are lucky to have your few hours backup time though! For legal reasons, we have to backup *everything*. MP>What kind of RS/6000's are you setting up? SP? I might have some more ideas. A mix of machines in the B50/H50/S80 class. Cheers, Steve Greatbanks <older stuff snipped>
