Attachment #1 Backup Schedule

Transcription

1 Attachment #1 Backup Schedule Summary Information Systems: Current DR Site VIC NetApp FAS2200 Series SAN with SnapMirror replication of all volumes from production SAN every hour on the hour o Dedicated SAN switch stack using two Cisco 2960S switches Two VMware host servers (sans licensing) operating in a powered on, but non-operational state UPS that provides approximately 30 minutes of run time Dedicated power circuit for UPS Dedicated AC unit for just the datacenter Cisco Unified Computing server running VMware vsphere and virtual machines of a CallManager, Unity server, and Emergency responder (Running load-balanced with CEN) Router with voice capabilities Dual PRIs with dedicated DIDs as well as full trunk group failover from Central PRI Trunk Group 3 Mbps Internet connection with static IP addresses (from PRIs - would require additional Telco support to make usable) Cisco ASA 5505 for Internet connection (not configured, not running at this time) What a Disaster Recovery Activation would look like Removing CEN IP addresses from use on the network to control failback (disconnect fiber/shut down ports, etc., network will auto-remove routes) Overlay Central IP addresses on necessary VIC Cisco equipment - VLANs (10, 11, 12, 28, 50, etc.) Mount SnapMirrored volumes on hosts, begin bringing up services in order (Both Domain Controllers, and then necessary services as needed) If a prolonged outage (i.e. construction necessary at Central to return operations, or other multi-week circumstances), initiate move of Internet IP addresses by TelePacific to Victorville if possible For Exchange, an IronPort appliance would be needed for inbound and outbound spam filtering. If an IronPort is not able to be moved (i.e. both are damaged at Central), our Microsoft EA allows us to use the Online Exchange Filtering from Microsoft that can be used in a pinch for basic inbound filtering (1 day config). For editing control on Call Manager and Unity Connection, the Publisher node must be online and operational. If the hardware containing the Publisher nodes can t be brought up from Central, the VMs may be restored from the backup that is SnapMirrored to Victorville. Phones would continue to work, but changes would not be possible until a publisher node was established. Services would need to be activated on a need-it-now basis. For example, once Domain support is running (AD, Exchange) pick the servers necessary for operations to function (Voyager DB, Voyager Web, Connect DB, both Connect Web servers) and leave out anything not completely necessary. In some cases it may be necessary to take services down while another service is brought up on a temporary basis depending on demand and system load.

2 What could happen to DR over the next year Completion of ASA configuration for use of the SmartVoice Internet circuit as a secondary Internet connection for the agency o Additional bandwidth that can be used for inbound and outbound traffic when primary connection is unavailable o Adds a second fail-over server using the Victorville ASA for EARS (ears2.hacsb.com) and update applicable AnyConnect configuration for automatic failover of client access. o Move HAIRONPORT02 from Central to Victorville, configure DNS MX records, firewall, and Exchange for new IP location. o If possible (will require assistance from someone like Nexus) configure AOP/LLC firewalls to have a second tunnel to Victorville should the primary Central tunnel fail. License vsphere, vcenter, and Windows Datacenter licensing on EA Evaluate cost of adding second Exchange server to EA for installation on Victorville hardware Build 2 additional Domain Controllers to live in Victorville permanently, reconfigure DHCP for 60/40 split scope, split DNS, reconfigure IP Helpers on all network routers that host DHCP d VLANs. What a Disaster Recover Activation would look like with above completed Removing CEN IP addresses from use on the network (disconnect fiber/shut down ports, etc., network will auto-remove routes) Overlay Central IP addresses on necessary VIC VLANs (10, 11, 12, 28, 50, etc.) Mount SnapMirrored volumes on hosts, begin bringing up services in order If a prolonged outage (i.e. construction necessary at CEN to return operations, or other multi-week circumstances), initiate move of IP addresses by TelePacific to VIC if possible or necessary. With split/secondary VPN tunnels for clients, configuration already established, the need to re-direct IP addresses would be greatly minimized. Exchange would continue to function utilizing the one surviving IronPort appliance and Internet connectivity through VIC. The Exchange DAG would take over primary mail routing functions and communication would be unaffected. Call control, voic , etc. would continue to function, however a publisher node would need to be restored from backup to allow configuration changes. Services would need to be activated on an as-needed basis as before, however, over all functionality with communication between sites and the outside world would continue largely unaffected. Licensing the additional vsphere servers would allow for always on servers to be maintained and running, second vcenter license would allow for a configuration controller for centralized management and simplified service restore. With a split-dhcp scope and split DNS, clients would need minimal if any reconfiguration to maintain services hosted by the HACSB and remote resources over the Internet. Split VPN tunnels (or secondary tunnels if split tunnels aren t feasible) for AOP/LLC sites would enable business continuity with little to no reconfiguration needed. Future Disaster Recovery Vision Not in any particular order: Additional Internet Connection at CEN provided over a different medium and different provider (i.e. Coax cable, cellular, etc.) with ASA configuration in failover mode Larger Internet connection at VIC to sustain additional load encountered during an Internet outage at CEN and/or CEN disaster Additional web front end for Connect and KnowledgeLake that live in VIC, potential second DB server with application replication If Voyager still hosted on-site, second DB server and web front ends hosted in VIC Implementation of VMware Site Recovery Manager for automated failover

3 Backup Schedules and Retention Attachment #1 Backup Schedule (Con t) Netapp SAN SnapShots - point in time block level copies of entire volumes

4 o Maximum 255 snapshots per volume o Hourly up to 9 hours o Daily up to 4 days o Weekly up to 4 weeks SnapMirror relationship to VV SAN replicates all volumes every hour Important note: recovery requires restore of entire volume(s) before files / data can be retrieved HABACKUP Microsoft Data Protection Management (DPM) Backs up all windows severs (listed below) DPM Definitions Retention Range - amount of time for which the data should be available for recovery Recovery Points Also known as a snapshot. A point in time copy of the protected data Synchronization - How frequent we want the source and backups to be synchronized (these are differential backups between the Recovery Points) CIFS backups (S Drive, Profiles, My Docs, etc.) -to-disk Retention SAN retention schedule (above) Recovery - SAN retention schedule (above) Sync SAN retention schedule (above) * Cifs are not DPM protected directly. Tftp job copies cifs shares data to attached drive on habackup to make available for tape backups. (most recent disk-to-disk backup) Retention: 2 weeks Recovery points - Daily Sync N/A SharePoint (Connect) Servers Retention - 5 days Recovery Point - 3x a day (8am, 12pm, 6pm) Sync - 15 min Retention - 2 weeks Recovery points daily Domain Controllers Retention - 8 days Recovery Point - 3x a day (8am, 12pm, 6pm) Sync - 30 min

5 Retention - 2 weeks Recovery points - daily Exchange Servers Retention - 14 days Recovery Point 45 min Sync N/A Retention - 2 weeks Recovery points - daily Server Systems Retention - 10 days Recovery Point - 3x a day (8am, 12pm, 6pm) Sync - 30 min Retention - 2 weeks Recovery points - daily SQL Servers Retention - 10 days Recovery Point - 15 Sync N/A Retention - 2 weeks Recovery points - daily Test and Development Retention - 10 days Recovery Point - Daily 6PM Sync - 12 min Retention - 2 weeks Recovery points - daily Voice (Cisco Unity and Call Manager) Backups Retention - 5 days Recovery Point - Daily 8:30pm Sync N/A

6 Retention - 2 weeks Recovery points - daily Voyager Retention - 10 days Recovery Point - 3x a day (8am, 12pm, 6pm) Sync - 15 min Retention - 2 weeks Recovery points - daily VisualHomes Retention - 14 days Recovery Point - 3x a day (8am, 12pm, 6pm) Sync - 15 min Retention - 3 weeks Recovery points - daily