I generally do a LOCK NODE prior to GENERATE BACKUPSET which I know will
take a long time.

I'm currently in a Disaster Recovery situation for several dozen client
nodes that were destroyed in a fire. I've locked them all, and removed
their associations with any schedule, to prevent inadvertent backups
which would cause unintended de-activation or expiration of valuable
pre-disaster files.

Expiration has not been an issue. New backups has, especially since a
new backup can trigger expiration of that node. Stop that node from
backing up until you fully restore it, by whatever means either by
normal client restore, or by delivering a generated backupset on a stack
of DVDs. Once you stop backup, then normal expiration will simply skip
over that node.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu



On Fri, 25 Jan 2008, Thomas Denier wrote:

>Earlier today I attempted to create a backup set for a very large
>file server. The process generating the backup set was running at
>the same time as our daily inventory expiration process. As far as
>I can tell, all went well until inventory expiration got to the system
>for which the backup set was being created, at which point a remarkably
>ugly deadlock condition occured. The backup set process, the inventory
>expiration process, and a tape reclamation process all stopped making
>headway, and client sessions were starting but not making any headway
>after they connected. I ended up cancelling the backup set process.
>
>Our server is at the 5.3.4.0 level and runs under mainframe Linux. The
>client involved is a Windows 2003 system with  5.3.4.0 client code.
>
>Is there a bug fix that will prevent the deadlock condition?
>
>What would happen if we tried to run a 'generate backupset' process
>that run through the normal backup window for the client involved?
>Extrapolation from the part of the backup set that completed before
>the deadlock suggests that the entire process would take 13 hours.
>This would make it a mathematical impossibility to avoid overlap
>with either the client backup window or the normal inventory
>expiration window.
>