2

Possible Duplicate:
periodically overridding NTP for simulation purposes

When we conduct our DR exercises, we have to rerun production batches from the previous day. In order to accommodate the rerunning of these batches, the system clocks on all our servers are moved back (9 hours for an internal exercise, or 24 hours if we involve our end users).

The Domain Controller will be started and NTP will be reconfigured. Then all the client machines will be started.

The time offset needs to be completed first.

Can anyone help with the steps to complete the system time offset, since this need to be completed before the rest of the servers are brought up?

Below is a high-level view, I need help filling in the blanks to create a procedure.

  1. Domain controller: change NTP Server configuration to point to local hardware clock as stratum 9
  2. Customer Unix server clients: Stop ntpd, run ntpdate <DC IP address>, start ntpd
  3. Infrastructure Unix servers (if necessary). Stop xntpd, and change clock manually.
Community
  • 1
Pete Ekanem
  • 29
  • 1
  • Do you already have a non-production NTP server running, which you can use for the test machines? – jscott Aug 18 '12 at 01:21

1 Answers1

3

I'm probably missing something. But I would just stop NTP for the DR exercise if it doesn't take too long. What am I missing? You seem to already have a plan.

  1. service ntpd stop
  2. date -s "now -9 hours"
  3. Run your batch in whatever manner you see fit.
  4. date -s "now +9 hours"
  5. service ntpd start

I hope all the time changes don't screw any thing else up... Might be a better idea to test DR in a segregated environment where you don't have to mess with the time in production.

Aaron Copley
  • 12,525
  • 5
  • 47
  • 68
  • Thanks Aaron; yes, the ideal situation is to test DR without messing with prod environment. But the basis of testing in this instance is in restoring the prod environment in an offsite DR location on stand by servers isolated from the production network which are rebooted with the image of the prod servers. The new prod (DR) servers takes in the ip of the failed prod servers, including a replacement DC with the gateway information. All presume, the complete outage of the prod site. – Pete Ekanem Aug 18 '12 at 01:47
  • So, will what I suggest work? Without messing with NTP itself? Or does DR take long enough that drift would be an issue? – Aaron Copley Aug 18 '12 at 01:53
  • You suggestion should work. The real problem is the test batch job. The test job is the batch job from previously executed in production the previous night prior the DR. The application owners want to compare the out from the previous day's prod run with the output from the DR test. – Pete Ekanem Aug 18 '12 at 14:14