> [...] As far as the person > who said the window should be shorter than your backup time, I have to > respectfully disagree. You really just need to make sure that your
Assuming you are referring to > 10. windows should be shorter than the backup. Since it isn't > frequency based it will re-run if given the chance. 268400. perhaps I could have explicitly stated that everything in the note applied to calendar-based scheduling. And 268400 is the technote reference to which the interested reader can refer for the details. > frequency is set longer than your backup window or you will start two > (or more) jobs within that period. Than again, that might be > what you['re] after Of course. Common solution for any user who has faced a more-than-once-daily requirement, and well-documented in the SAG--at least for the last couple of releases. > network delay (for whatever reason.) I'm not skimpy with any of my > backup windows - especially over the weekend when no one really cares > when the backup fires, as long as its done by Monday morning. I'm a huge fan of max windows, every-day windows, and spreading the load by schedulng fulls on a frequency requirement rather than specific days of the week. That's often a tough sell, of course, and business-requirements dictate whether it's feasible. Easier to sell when first formalizing SLAs and redesigning from scratch, but that's another topic. _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
