Master Server Schedule
When recovering a master server, consider the state of the configured backup schedule. If the master is being recovered into an existing Enterprise and expected to immediately pick up and continue backup operations, then the master server can be recovered, spot checked for functionality, and setup to continue operations.
If however, the master server is being recovered after a disaster where many recoveries must be performed, it is unlikely that running a backup schedule is desired until your recovery work is completed. You can do this in one of several ways.
Using the management console, “Hold” each scheduled job. You may need to do this for all the scheduled jobs, depending on how long you expect Enterprise server recovery to take.
If you would prefer to defer the schedule for a short period of time, you can do so by passing the –s parameter to sssched with the number of minutes to suspend the Catalog.
For a Windows master server, complete the following procedure:
Stop the cmagent service.
Open regedit and drill down to the software registry where cmagent and all other product options are saved.
Create a new string value named “SSSCHED”. Once created, add –s followed by the number of minutes desired. For example, an entry for one hour is the following:
Restart cmagent.
For a Linux master, complete the following procedure:
Stop the cmagent process. Observe that the besched process is no longer running.
Edit the bin/sssched script. Add –s followed by the minutes at the end of the exec line. An example for one hour is:
Start the cmagent process again. Observe that the besched process is now running.
From the management console, observe that all jobs scheduled to run are placed into "suspended" mode. These jobs are released when the number of minutes indicated runs out. Note that if you leave this parameter in place, the next time you restart cmagent, the scheduler holds jobs for the requested number of minutes. Remember to remove this parameter after the master server recovery. Using this parameter does not prevent you from manually running new jobs, including restores. However, depending on the number of jobs in the Enterprise and the expected schedule, when the allotted time runs out, your master server and backup Enterprise could see a significant spike in activity.
Alternatively, you can completely disable the schedule if needed. This is useful when the amount of restore work is expected to take a significant amount of time. It is also convenient for restore testing in cases where you never intend on running the usual backup schedule.
To disable the schedule entirely, complete the following procedure:
Stop all master server processes.
Navigate to the "sched" directory where the master server software is installed.
Move the files “index” and “schedule” to a temporary location.
Start up the master server processes.
The master then starts up with a completely empty schedule. An empty schedule could make things easier on data recover staff as multiple people try to run restore jobs in parallel.
When recovery operations are complete, reverse the procedure above to recover the backup schedule if desired:
Stop all master server processes.
Move the files “index” and “schedule” back to their original location.
Start up the master server processes.
Note that doing so wipes out the log of recovery jobs that were run. However, the recovery job logs are still available if needed.
There are many circumstances where a new base backup can be performed from a recovered client machine for proper protection. See Continuing Backups and New Base Backups after Master Server Recovery. Consider eliminating the old backup schedule and then build and schedule new backup jobs as the servers in your Enterprise are recovered and stabilized. If the existing schedule is preserved, then you may need to manually reset the change journals on clients or generate File or NDMP base backups. See Gaps in Catalog Restore and Backup Schedule.
Last updated