If you take it a step further, and by no means is this exact scenario a suggestion, just food for thought....
Lets say you have 2 identical servers. We're not talking about Microsoft clustering, as frankly I dislike it. This would be internally handled at the service level of VC.
Server1 (Primary): All jobs configured on it, enabled/disabled as necessary, etc...
Server2 (Secondary/Stopped): Sitting there constantly importing the configuration of Server1 every few minutes or on a schedule, that is not dependant on tasks/jobs. It would be more of a core feature that runs as part of the server settings in Server2. Somehow in the Server settings on Server2, configure it to replicate all jobs/tasks/credentials/conditions/etc... like taking a backup on Server1 and importing 'all' on Server2, keeping Server2 in synch while still stopped/not running any jobs. That internal synch from Server1 would only be active while Server2 is stopped. As soon as you start Server2, it would stop synching from Server1 and if/when you wanted to bring Server1 back into the mix as Primary again, you'd backup Server2, stop it, and import on Server1... which would bring Server1 back into production while Server2 resumes it's automatic synching.
I dunno if this is the best way at all, but it's something to consider. Obviously if you have underlying files/folders/scripts etc kept locally and not via UNC path you'd have to replicate those between servers all the time too.
Our Disaster plan right now is to back up our server settings every hour with a date/timestamp and keep 30 days worth. Those get backed up nightly by our enterprise backup solution, and in an 'event', we'd restore the server settings and underlying data drive (scripts/etc..) to a server at our D.R. site, and run from there instead. But there are always potentials for better solutions. Automated solutions are even better, but only after vetting them out in many scenarios.
Brian