boebackupanddrsvcsguide

Recovery ServicesBackup and Disaster Recovery XI

Darrin Joncas, Advanced Services GroupApril 8, 2008

© SAP 2008 /

Delivery Areas

Disaster Recovery: Implementation types – Level 1, Level 2, Level 3

Topics Architecting the Process (MS VISO) Documenting the Process Infrastructure Components File Repository Server Local vs. SAN CMS Database, Audit Database, KPI and other 3rd party Databases Geographical Locations

Backup Recovery:

Topics Architecting the Process (MS VISO) Documenting the Process Infrastructure Components File Repository Server CMS Database, Audit Database, KPI and other 3rd party Databases Synchronization and Scheduling backups

Agenda

© SAP 2008 /

Disaster Recovery

Implementations Types: This presentation focus is on Level 2 implementation

Level 1 (1-2 weeks) Level one clients are small implementations of XI that have 1-3 production servers. The FRS is most likely a local

installation on the server. Recovery Services include CMS database, Audit Database and any KPI. Level 2 (2-3 weeks)

Level two clients are medium implementations of XI that have 3-5 production servers. The FRS is most likely installed on a shared drive. The drive can be located on a Fileshare or SAN. Recovery Services include CMS database, Audit Database and any KPI. Also, include Data Integrator and other Business Objects software as well as 3rd party datasources such as APOS KPI

Level 3 (3-7 weeks) Level three clients are larger clustered implementations of XI that have 5++ production servers in one or many

geographically dispersed environments. The FRS would be located on a clustered SAN environment using NAS heads, Veritas, Microsoft Clustering, or some other 3rd party tool. Recovery Services include CMS database, Audit Database and any KPI. Also, include Data Integrator and other Business Objects software as well as 3rd party datasources such as APOS KPI. These datasources can be located in multiple geographically dispersed areas.

Agenda

© SAP 2008 /

Backup and Disaster Recovery Definitions/Terms (WIKI - external): Disaster Recovery Backup Recovery Fault Tolerance High Availability Failover Load Balancing Clustering Active vs. Passive SAN/NAS FRS/CMS Synchronization Vertical and Horizontal Scaling Infrastructure Architect Trusted Advisor Role Lifecycle Management

DEV vs. TEST vs. QA vs. STAGED vs. PROD Environments

Agenda

© SAP 2008 /

Definitions/Terms

Disaster Recovery Disaster Recovery is the process, policies and procedures of restoring operations critical to

the resumption of business, including regaining access to data (records, hardware, software, etc.), communications (incoming, outgoing) workspace, and other business processes after a natural or human-induced disaster.

Common Strategies– Backups made to tape and sent off-site at regular intervals (preferably daily) – Backups made to disk on-site and automatically copied to off-site disk, or made directly

to off-site disk – Replication of data to an off-site location– Local mirrors of systems and/or data and use of disk protection technology such as

RAID

© SAP 2008 /

Definitions/Terms

Backup Recovery Backup Recovery: backup refers to making copies of data so that these additional copies

may be used to restore the original after a data loss event. These additional copies are typically called "backups." Backups are useful primarily for two purposes.

The first is to restore a state following a disaster (called disaster recovery). The second is to restore small numbers of files after they have been accidentally deleted

or corrupted.

© SAP 2008 /

Definitions/Terms

Fault Tolerance Fault-tolerance or graceful degradation is the property that enables a system to continue

operating property in the event of the failure of (or one or more faults within) some of its components

The basic characteristics of fault tolerance require:– No single point of failure – No single point of repair – Fault isolation to the failing component – Fault containment to prevent propagation of the failure – Availability of reversion modes

© SAP 2008 /

Definitions/Terms

High Availability High availability is a system design protocol and associated implementation that ensures a

certain absolute degree of operational continuity during a given measurement period.– Availability refers to the ability of the user community to access the system, whether to

submit new work, update or alter existing work, or collect the results of previous work. If a user cannot access the system, it is said to be unavailable. Generally, the term downtime is used to refer to periods when a system is unavailable.

– Planned Vs Unplanned downtime

© SAP 2008 /

Definitions/Terms

Failover Failover is the capability to switch over

automatically to a redundant or standby computer server, system, or network upon the failure or abnormal termination of the previously active server, system, or network. Failover happens without human intervention and generally without warning, unlike switchover.

– The automation is done using a "Heartbeat" cable that is connected to the two servers. As long as there is a "Pulse or heartbeat" from the main server to the second server, the second server will not initiate its systems.

Quorum1GB LUNF:\ Drive1TB LUN

Active Link to Q:\ (Quorum) on SANActive Link to F:\ on SAN

Passive Link to Q:\ (Quorum) on SANPassive Link to F:\ on SAN

Active Passive

© SAP 2008 /

Definitions/Terms

Load Balancing Load Balancing is a technique (usually performed by load balancers) to spread work between two or

more computers, network links, CPUs, hard drives, or other resources, in order to get optimal resource utilization, throughput, or response time. The balancing service is usually provided by a dedicated program or hardware device (such as a multilayer switch).

Load-balancing clusters operate by having all workload come through a load-balancing front ends, – Persistence or “Stickiness” -sending the client to the same backend server

CMS_PROD_1

CMS_PROD_2

CMS_PROD_3

CMS_PROD_4

CMS_PROD_5

Active

Active

Passive

Passive

Passive

TOMCAT/APACHE

TOMCAT/APACHE

BIG IP

© SAP 2008 /

Definitions/Terms

Clustering – Not XI clustering High-availability clusters (also known as HA Clusters or Failover Clusters)

– are computer clusters that are implemented primarily for the purpose of improving the availability of services. They operate by having redundant computers or nodes which are then used to provide services when system components fail.

– HA cluster implementations attempt to build redundancy into a cluster to eliminate single points of failure, including multiple network connections and data storage (SAN)

In order to run in a high-availability cluster environment, an application must satisfy at least the following technical requirements:– There must be a relatively easy way to start, stop, force-stop, and check the status of the

application. – The application must be able to use shared storage (NAS/SAN). – The ability to restart on another node at the last state before failure using the saved state from the

shared storage. – Application must not corrupt data if it crashes or restarts from the saved state.

– Commonly used clustering services are – Veritas Cluster Server - multi-platform– Microsoft Cluster Server (MSCS) - Windows only

© SAP 2008 /

Definitions/Terms

Clustering Active Vs. Passive Services

Active/Active — Traffic intended for the failed node is either passed onto an existing node or load balanced across the remaining nodes. This is usually only possible when the nodes utilize a homogeneous software configuration.

Active/Passive — Provides a fully redundant instance of each node, which is only brought online when its associated primary node fails. This configuration typically requires the most amount of extra hardware.

Other– N+1 — Provides a single extra node that is brought online to take over the role of the node that has failed. In the case of heterogeneous software

configuration on each primary node, the extra node must be universally capable of assuming any of the roles of the primary nodes it is responsible for. This normally refers to clusters which have multiple services running simultaneously; in the single service case, this degenerates to Active/Passive.

– N+M — In cases where a single cluster is managing many services, having only one dedicated failover node may not offer sufficient redundancy. In such cases, more than one (M) standby servers are included and available. The number of standby servers is a tradeoff between cost and reliability requirements.

– N-to-1 — Allows the failover standby node to become the active one temporarily, until the original node can be restored or brought back online, at which point the services or instances must be failed-back to it in order to restore High Availability.

– N-to-N — A combination of Active/Active and N+M clusters, N to N clusters redistribute the services or instances from the failed node among the remaining active nodes, thus eliminating (as with Active/Active) the need for a 'standby' node, but introducing a need for extra capacity on all active nodes.

© SAP 2008 /

Definitions/Terms

SAN/NAS SAN is an architecture to attach remote

computer storage devices (such as disk arrays, tape libraries and optical jukeboxes) to servers in such a way that, to the operating system, the devices appear as locally attached. Although cost and complexity are dropping, as of 2007, SANs are still uncommon outside larger enterprises.

By contrast to a SAN, Network Attached Storage (NAS) uses file-based protocols such as NFS or SMB/CIFS where it is clear that the storage is remote, and computers request a portion of an abstract file rather than a disk block.

Production Server

CMS_AUDIT

CMS

3

Oracle DW Corporate Data

4

Business Objects Infoview Portal

DMZ

1

Apache/Tomcat – supported version jdk 1.4 and Tomcat 5.0

Production Server

1

Apache/Tomcat – supported version jdk 1.4 and Tomcat 5.0

2

@CLUSTER

Fibre Switch

SAN

LUN (Logical Unit Number)

HBAHBA

ACTIVE FRS Services 05A

PASSIVE FRS Servies on 05B

\\”LUN NAME”\C$\Enterprise 11.5\FileStore\Input

\\”LUN NAME”\C$\Enterprise 11.5\FileStore\Output

FRS

LDAP Server

© SAP 2008 /

Definitions/Terms

FRS and the CMS/AUDIT/KPI FRS/CMS Synchronization

Add the file to the FRS storage. C:\Program Files\Business Objects\

BusinessObjects Enterprise11.5\FileStore\Input

Add a reference to that file in the InfoObject’s SI_FILES property bag.

It will create this propertybag if your InfoObject does not already have one.

<propertybag name="SI_FILES" type="Array">

<property name="SI_PATH" type="String">frs://fooPath/</ property>

<property name="SI_NUM_FILES" type="Long">2</property>

<property name="SI_FILE1" type="String">foo1.rpt</property>

<property name="SI_FILE2" type="String">foo2.jpeg</property>

</propertybag>

The above array would be stored in XRLv3 as:

Note: The well-known properties should be stored as numbers but are left as “_Name” to show how custom properties are represented.

3:_SI_FILES={3:_SI_PATH=frs://fooPath/,P&_SI_NUM_FILES=2,3&

_SI_FILE1=foo1.rpt,P&_SI_FILE2=foo2.jpeg,P&},I&

© SAP 2008 /

Definitions/Terms

Vertical and Horizontal Scaling

Vertical Scaling The addition of software processing

services to an infrastructure system Horizontal Scaling

The addition of hardware processing services to an infrastructure system

The BI Platform is a multi-tier system consisting of server components and client-side applications. The system can be easily expanded: all server components can be scaled vertically and horizontally, and all processing components support load balancing. Security is enforced across all tiers.

From a pricing perspective the first core is considered 1 cpu. Each additional core is considered .5 cpu. Therefore a quad core processor equals 2.5 cpu (1+.5+.5+.5= 2.5). A dual core processor is treated the same way. The first core is considered 1 cpu. The second core is considered .5 cpu. Therefore a dual core processor equals 1.5 cpu (1+.5= 1.5). You then multiple the per cpu price times the number of cpu.

© SAP 2008 /

Disaster Recovery Process

Disaster Recovery Process– A Disaster Recovery architecture can be divided into 2 different types.

– Available: Most Disaster Recovery designs will fall into this category. Essentially, the Disaster Recovery system is available for use if the main production BI system becomes catastrophically unavailable. When the system becomes available would be a business process decision, but most likely within 4 hours.

– Highly Available: Rare - the Disaster Recovery system is available for use immediately if the main production BI system becomes catastrophically unavailable

The first step in creating a Disaster Recovery Architecture is gathering information “Squirreling”

– Gather data about the production system – In most cases a Disaster Recovery system will not be located in the same building or geographical area as the production system. It is important to understand how this will affect you in your Disaster Recovery design

– Gather data about the people in the system – Disaster Recovery staff may not be the same staff that work on the production system. It is important to understand their relationship to the production staff. The Disaster Recovery location may be thought of as a datahousing center without application implementation responsibility

© SAP 2008 /


Disaster Recovery Process– People I need to consider (Laundry List) – Remember, You are the Trusted Advisor

1. DBA (Local and Remote)2. Network Administrators (Local and Remote)3. Business Intelligence Administrator (Local and Remote)4. Backup and Recovery Administrators (Local and Remote)5. Business Line (needed for time lines, types of data)6. 3rd party staff - Either outsourced or geographically removed7. ****AVAILABILITY****

© SAP 2008 /


Disaster Recovery Process– Components I need to consider (Laundry List)

MAIN Considerations

1. BOXI Server (s)2. Database (CMS, Audit, Reporting Datasources, KPI, 3rd party additional sources APOS)3. FRS4. Custom code (SDK, Web Pages, images)5. Network Topologies (Bandwidth, Network Latency) 6. Server OS (Service Packs)7. Geographical location8. Ports, ODBC, Firewalls, Proxies9. ****OTHER DTAT/DATABASE SOURCES, LOV’S AND LOOKUPS****

© SAP 2008 /


Disaster Recovery Process– Components I need to consider (Laundry List)

Other Considerations

1. Client Browser2. Load Balancing3. Web Application Servers 4. Web Server 5. Network-layer/Application-layer6. Intranet/extranet7. SSL8. IIE Certs9. Java Certs10. Load Balancer Cets11. Security, Authentication, Authorization and SSO12. Kerberos13. Active Directory/LDAP

© SAP 2008 /


Disaster Recovery Process (Scenario 7 server clustered environment with FRS on a SAN)

– Environment and Assumptions– Production is up and running– You have contacted all the parties mentioned– Client wants a Disaster Recovery environment that will be available

in 2 hours and performs identically with production– Client Disaster Recovery data will be up to date to production data

every 5 minutes– FRS is 200+ gig– Authentication is LDAP (SSO – not silent single sign on)– JAVA or .Net Web servers with no SSL– CMS is SQL Server

All 7 servers are members of the same cluster– In our Prod example server 1 and 2 are active CMS and 3-7

are in a disabled state– In Disaster Recovery 1-4 are in a disabled state for

Exercise/Test mode

31 42

@serverPRODCluster Members 1-7

3 - 7 are in a disabled state PROD Mode

5 6 7

@serverPRODCluster Members 1-7

1-4 are disabled state DR Mode and Exercise

© SAP 2008 /


Disaster Recovery Process (VISO) – Diagram it out

© SAP 2008 /


Disaster Recovery Process Assumptions

– Production Application servers (1,2,3) down (power off) *– Production SQL server down (just the SQL instance)– Disaster Recovery Application servers installed with FRS input/output/temp directory set to default– Disaster Recovery Application servers installed with CMS services set to manual– Disaster Recovery Application servers have different ODBC names for Disaster Recovery environment– Disaster Recovery servers down - cluster 4,5,6 (CMS services down)– Production CMS/FRS replication complete– SAN -> SAN -> FRS server (FRS) (started/running state)– SAN -> SAN -> Disaster Recovery SQL Server DB (CMS) (started/running

state)– No firewall, IP, ping issues with Disaster Recovery servers– All O/S server patches installed– BCV split completed

* Note: DR clusters are part of Prod clusters at this point. This process is explained in the next 3 slides

© SAP 2008 /


Cluster Member 4

(BOXI)

Cluster Member 5

(BOXI)

Cluster Member 6

(BOXI)SERVER\ SQLDB

DR ODBC Connections:

ODBCCMS ODBCAUDIT ODBCKPIODBCOTHER

Step 1 - Create ODBC and point your Disaster Recovery cluster members to the ODBC that matches your Database Disaster Recovery environment

At this point, your DR cluster members 4,5,6 are separate from prod 1,2,3

© SAP 2008 /


Step 2 - Change your CCM to point to your Disaster Recovery CMC cluster member services to the ODBC that matches your Database Disaster Recovery environment

Each of the 4,5,6 cluster member needs to be configured to the same cluster group NAME as production, although the data ODBC point to DR

At this point we are joining the DR cluster to the prod cluster – this is important when we have to test and switch over from production to DR. The CMS will store the cluster name and because it is replicated from production, DR must belong to the @prod.

In essence, we are making DR aware of prod, even though the FRS and CMS are interdependent form production to DR

Cluster Member 4

(BOXI)

Cluster Member 5

(BOXI)

Cluster Member 6

(BOXI)

Change CCM to point to DR

ODBCODBCCMS ODBCAUDIT ODBCKPIODBCOTHER

© SAP 2008 /


Step 3 - Start the service on DR

The DR IFRS and OFRS point to the replicated DR location and the CMS service points to the replicated CMS (The CMS DB knows about all 7 servers in the cluster.)

Change your FRS to pint to the shared replicated SAN location – restart IFRS and OFRS and CMS after changing location in the WEB CMC

Note* You may find some installations with the IFRS and OFRS root dir hard coded into their services of the windows CCM – Make sure to delete this reference if found

Cluster Member 4

(BOXI)

Cluster Member 5

(BOXI)

Cluster Member 6

(BOXI)

Start/enable DR servicesCMS (4 only)Cacheserver

ConnectionserverDeskICacheServer

DeskIJobServerDeskIReportServerdestinationserver

Eventserver (4 only)Pageserver

ListOfValuesJobserverProgramserver

RASReportjobserver

ScoreCard_DF.jobserverWeb_IntelligenceJobServer

Web_IntelligenceReportServeActive ( IFRS & OFRS ) (4)

Passive ( IFRS & OFRS ) (5,6)

© SAP 2008 /


Step 4 - Test your DR - Remember, you will have a completely different Web Application Server environment, so any customizations done in production may not be available and can affect testing.

These are the “Other” considerations1. Client Browser2. Load Balancing3. Web Application Servers 4. Web Server 5. Network-layer/Application-layer6. Intranet/extranet7. SSL8. IIE Certs9. Java Certs10. Load Balancer Cets11. Security, Authentication, Authorization and SSO12. Kerberos13. Active Directory/LDAP

Cluster Member 4

(BOXI)

Cluster Member 5

(BOXI)

Cluster Member 6

(BOXI)

Web Server 1DR

Web Server 2DR

Testing begins log into infoviewview report historyprint reportexport to different format

create a new report

© SAP 2008 /


Step 5 - Test your DR

Condition 1. Runtime:

Each Report will be run separately to determine the load placed upon each server process. These loads will be evaluated to measure which reports should be run at what times during the day.

Condition 2. Stress

Each Report job will be scheduled to run at the same time to test the effect of multiple job requests on the servers. In addition reports will be altered by each user after they are run to test and determine wait times and any point of failure.

Condition 3. Max

All Reports will be run simultaneously to determine the breaking point of the current architecture. This will require many users to log on and simulate a peak utilization need of the finished Reports. Each user will run and query multiple documents and report the results.

In addition to this testing, network evaluations will be undertaken to determine any bottlenecks in the architecture and discrepancies in network availability over various points in the day and week. This will be accomplished via network scan techniques (Net Scan, Pings etc). We will work with the Network and Database team at this time.

SQL: All SQL queries will be run outside of the Business Objects Environment to determine real time database query speed.

© SAP 2008 /


Step 6 - Recovering back to Production – Stop all services on DR. Just as you replicated the CMS and FRS changes from Prod to DR, now you must replicate those changes (if any) from DR back to Prod.

Cluster Member 4

(BOXI)

Cluster Member 5

(BOXI)

Cluster Member 6

(BOXI)

Stop/disable DR servicesCMS (4 only)Cacheserver





RASReportjobserver



Passive ( IFRS & OFRS ) (5,6)

© SAP 2008 /


Step 7 - After SQL Server Prod box has been recovered, start the SQL Server CMS instance

Prod Database server

SERVER \ SQLDB

Start up PROD

SQL instance

© SAP 2008 /


Step 8 - Start all Prod Services – It is extremely important to remember to leave your FRS in a on but disabled state – you cannot change the FRS location once you point back to the prod CMS if your Prod servers cannot see the DR FRS file storage location.

Cluster Member 1BOXI



Start/Enable PROD servicesCMS (1 only)Cacheserver





RASReportjobserver



Passive ( IFRS & OFRS ) (2,3,4)


© SAP 2008 /


DONE - Now you have completed a highly available DR model, make sure to test production.

Your CMS clustered services should be aware of Prod in DR and DR in Prod

Your CMS DB and FRS FileStore are replicated and are aware of the other





Web Server 1PROD

Web Server 2PROD

Test Production

© SAP 2008 /

Backup Recovery Process

Backup Recovery Process “Backup issue” definition:

– The Business Objects Central Management Server (CMS) database contains reference addresses to reporting objects that are housed in a separate report object file storage area, managed by the File Repository Server (FRS). The CMS and the FRS must have complete referential integrity without the benefit of the referential integrity that would normally be provided by a RDBMS managing the two stores. This distributed “reference pointer to report object” architecture presents a data recovery issue that could prevent successful recovery of the application environment.

– The difference in size between the CMS database and the FRS report object share requires different lengths of time to complete the backup process. Most company Backups as currently organized will not preserve the referential integrity of the CMS database and the corresponding FRS objects because of the likelihood that the contents of one of the stores (CMS or FRS) will change while the FRS is being backed up.

– A backup and restore solution is needed that preserves for restoration a single and concurrent point in time for the CMS and FRS contents to ensure that the backups will be completed without the contents of each changing during the backup process. The CMS/FRS references will then retain their integrity.

© SAP 2008 /


Backup Recovery Process 3 ways to do a backup

– You will need to use a manual process if the FRS is larger than 2gig of data – this applies to the import wizard and biar export

– Import Wizard – (See administration guide)– BIAR from command line– Manually

XIR2 Command line Biar file – Only export is available in XIR2

CLASSPATH=%CLASSPATH%; BOE_installdir/bobje/java/libCommand Line:– java -jar InstallEntSdkWrapper.jar “CMSNAME:6400" “MyAdminUser” “MyAdminPwd"

secEnterprise MyBIApplication.biar

XI3.0 Command line Biar file - Only export is available in XI3.0

– BIAR Engine (biarengine.jar) is available in BusinessObjects Enterprise XI 3.0 to support import and export of BIAR files within repository. Apache Derby (a small footprint database) is used for BIAR to Live system or Live system to BIAR workflow to get around the limitation of BIAR files in BusinessObjects Enterprise XI R2. Instead of loading all objects into memory, system loads the objects into Derby database temporarily prior to committing to BusinessObjects Enterprise or to the BIAR file.

– BIAR Engine Command Line The default location of the biarengine.jar is stored in C:\ProgramFiles\Business Objects\common\4.0\java\lib.

– To run the biarengine.jar, type on the command line:

– Java –jar biarengine.jar <Property File>

© SAP 2008 /


Backup Recovery Process Using the BIAR Engine command line to export objects

– A properties file must be prepared prior to this scenario.

Double-click the ExportFile.properties list item.– This file contains all the configuration information

that is needed by the BIAR engine to run the export.– Click the Command Prompt. – In the Command Prompt, navigate to the directory

where the BIAR engine is located.

The BIAR Engine can be found under Program Files\Business Objects\common\4.0\java\lib

– Enter the desired information into the field. Enter "D:".– Enter the desired information into the field. Enter "cd

Program Files\Business Objects\common\4.0\java\lib".– To run the BIAR Engine, use the following syntax:

java -jar biarengine.jar <your properties file>– Enter the desired information into the field. Enter

"java -jar biarengine.jar C:\ExportFile.properties".– Notice BIARExport1.biar is created as a result.– In this scenario, you have export objects using the

BIAR Engine command line. End of Procedure.

© SAP 2008 /


Backup Recovery Process– Manually

– STOP Services

– STOP Database Processes– Backup the FRS and CMS at the SAME time– HOT vs Cold backups

© SAP 2008 /


Backup Recovery Process Much simpler then DR (Only two components to consider – the CMS and the FRS and any

custom code that directly affects the CMS and FRS)

– The CMS is responsible for maintaining a database of information about your Business Objects Enterprise system, which other components can access as required. The data stored by the CMS includes information about users and groups, security levels, Business Objects Enterprise content, and servers.

– The CMS also maintains the Business Objects Enterprise Repository, and a separate audit database of information about user actions. This data allows the CMS to perform its four main tasks

Maintaining security Managing objects Managing servers Managing auditing

© SAP 2008 /


Backup Recovery Process– File Repository Server (FRS)

There is one input and one output File Repository Server (FRS) in every Business Objects Enterprise implementation. The input FRS manages all the report objects that have been added to the system

– Input File Repository ServiceThe location of where the input File Repository Server stores the input repository must have a sufficient enough disk space to store all report objects (templates) that have been added by the administrator or end user. The input FRS only holds the report template so typically the reports are not that large in size.

– Output File Repository ServiceThe location of where the output File Repository Server stores the output repository must have sufficient enough disk space to store all instances (report files with saved data) generated by the Job Server.

© SAP 2008 /


Backup Recovery Process– The FRS and CMS backup process should be automated and coordinated at the exact

same time. This can be accomplished via autosys jobs, Scripts, 3rd party tools

– Backing up the FRS – Coordinate this time – Create a batch file that can be run based on a file event– Ie).– echo *** MAKE SURE ALL SERVICES ARE STOPPED - CHECK THE CCM (Central Management

Server)3:59 PM 4/30/2007 – you can auto stop and start services as well.

– echo * * * Backup * * *– rem "replace servername"– xcopy /r /i /s /e /y "C:\Program Files\Business Objects\BusinessObjects Enterprise 11.5\FileStore" "\\DEN-

L-01-DJONCA\c$\Backup_filestore"– rem run the next line ONLY once then rem it out– at 10:00PM /every:m,t,w,th,f,s,su c:\filestore.bat– for /f "tokens=2,3,4 delims=/ " %%a in ('date /t') do set fdate=%%a%%b%%c.txt– ECHO. | DATE |FIND /i "current">>\\DEN-L-01-DJONCA\c$\Backup_filestore\%fdate%– ECHO Backup is complete.

© SAP 2008 /


Backup Recovery Process– differential backups of the entire “H” drive (every night)– full backups completed weekly. These off-site backups are retained for 6 months.

– Screenshot of SQL backup schedule:

© SAP 2008 /


Backup Recovery Process – Going back to Production

1. Stop all services – suggest create a BATCH file

2. Install new XIR2 environment

3. Update ODBC– The name of the ODBC DSN– The name of the target database– The type of target database (Oracle, SQL Server, Sybase, etc.)– The user ID and password used to connection to the database– A listing of the reports that rely on the data source– Any other pertinent information that an administrator can use to recreate the

data source manually if necessary

4. Copy FRS to new location

5. Copy CMS to new location

6. Copy Database to new location

7. Copy Custom Code

8. Perform any System authentication configuration

9. Start Services

10. Test

boebackupanddrsvcsguide

Documents

recovery servicesbackup

audit database

implementation level

weeks level

apos kpi level

san cms database

active server

implementation types