Recovery Services

Backup and Disaster Recovery XI

Darrin Joncas, Advanced Services Group April 8, 2008

Agenda

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

SAP 2008 / Page 2

Agenda

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.

SAP 2008 / Page 3

Agenda

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

SAP 2008 / Page 4

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 / Page 5

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 / Page 6

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 / Page 7

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 / Page 8

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.

Active

Passive

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.

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

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

Quorum 1GB LUN F:\ Drive 1TB LUN

SAP 2008 / Page 9

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
TOMCAT/APACHE

CMS_PROD_1

Active
BIG IP

CMS_PROD_2
Passive Passive

CMS_PROD_3
Passive

Active CMS_PROD_4

TOMCAT/APACHE

CMS_PROD_5
SAP 2008 / Page 10

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 / Page 11

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 / Page 12

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.

1
DMZ

1
Business Objects Infoview Portal

Apache/Tomcat supported version jdk 1.4 and Tomcat 5.0

Apache/Tomcat supported version jdk 1.4 and Tomcat 5.0

@CLUSTER

Production Server
CMS CMS_AUDIT

Production Server

Oracle DW Corporate Data

ACTIVE FRS Services 05A FRS

LDAP Server

PASSIVE FRS Servies on 05B

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

HBA

HBA

Fibre Switch
LUN (Logical Unit Number)

SAN

SAP 2008 / Page 13

Definitions/Terms

FRS and the CMS/AUDIT/KPI

<propertybag name="SI_FILES" type="Array"> <property name="SI_PATH" type="String">frs://fooPath/</ property> <property name="SI_NUM_FILES" type="Long">2</property>

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 InfoObjects SI_FILES property bag. It will create this propertybag if your InfoObject does not already have one.

<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 / Page 14

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 / Page 15

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 / Page 16

Disaster Recovery Process

Disaster Recovery Process People I need to consider (Laundry List) Remember, You are the Trusted Advisor
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 removed 7. ****AVAILABILITY****
1.

SAP 2008 / Page 17

Disaster Recovery Process

Disaster Recovery Process Components I need to consider (Laundry List) MAIN Considerations
1. 2. 3. 4. 5. 6. 7. 8. 9.

BOXI Server (s) Database (CMS, Audit, Reporting Datasources, KPI, 3rd party additional sources APOS) FRS Custom code (SDK, Web Pages, images) Network Topologies (Bandwidth, Network Latency) Server OS (Service Packs) Geographical location Ports, ODBC, Firewalls, Proxies ****OTHER DTAT/DATABASE SOURCES, LOVS AND LOOKUPS****

SAP 2008 / Page 18

Disaster Recovery Process

Disaster Recovery Process Components I need to consider (Laundry List) Other Considerations
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Client Browser Load Balancing Web Application Servers Web Server Network-layer/Application-layer Intranet/extranet SSL IIE Certs Java Certs Load Balancer Cets Security, Authentication, Authorization and SSO Kerberos Active Directory/LDAP

SAP 2008 / Page 19

Disaster Recovery Process

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

@serverPROD Cluster Members 1-7 3 - 7 are in a disabled state PROD Mode

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

@serverPROD Cluster Members 1-7 1-4 are disabled state DR Mode and Exercise

SAP 2008 / Page 20

Disaster Recovery Process

Disaster Recovery Process (VISO) Diagram it out

SAP 2008 / Page 21

Disaster Recovery Process

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 / Page 22

Disaster Recovery Process

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
Cluster Member 4 (BOXI)

DR ODBC Connections: ODBCCMS ODBCAUDIT ODBCKPI ODBCOTHER Cluster Member 5 (BOXI)

Cluster Member 6 (BOXI) SERVER\SQLDB

SAP 2008 / Page 23

Disaster Recovery Process

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 6 (BOXI) Cluster Member 4 (BOXI)

Change CCM to point to DR ODBC ODBCCMS ODBCAUDIT ODBCKPI ODBCOTHER Cluster Member 5 (BOXI)

SAP 2008 / Page 24

Disaster Recovery Process

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.)
Cluster Member 4 (BOXI) Start/enable DR services CMS (4 only) Cacheserver Connectionserver DeskICacheServer DeskIJobServer DeskIReportServer destinationserver Eventserver (4 only) Pageserver ListOfValuesJobserver Programserver RAS Reportjobserver ScoreCard_DF.jobserver Web_IntelligenceJobServer Web_IntelligenceReportServe Active ( IFRS & OFRS ) (4) Passive ( IFRS & OFRS ) (5,6)

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 5 (BOXI)

Cluster Member 6 (BOXI)

SAP 2008 / Page 25

Disaster Recovery Process

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 considerations
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Testing begins log into infoview view report history print report export to different format create a new report

Client Browser Load Balancing Web Application Servers Web Server Network-layer/Application-layer Intranet/extranet SSL IIE Certs Java Certs Load Balancer Cets Security, Authentication, Authorization and SSO Kerberos Active Directory/LDAP

Web Server 1 DR

Web Server 2 DR

Cluster Member 4 (BOXI)

Cluster Member 5 (BOXI)

Cluster Member 6 (BOXI)

SAP 2008 / Page 26

Disaster Recovery Process

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 / Page 27

Disaster Recovery Process

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)

Stop/disable DR services CMS (4 only) Cacheserver Connectionserver DeskICacheServer DeskIJobServer DeskIReportServer destinationserver Eventserver (4 only) Pageserver ListOfValuesJobserver Programserver RAS Reportjobserver ScoreCard_DF.jobserver Web_IntelligenceJobServer Web_IntelligenceReportServe Active ( IFRS & OFRS ) (4) Passive ( IFRS & OFRS ) (5,6)

Cluster Member 6 (BOXI)

SAP 2008 / Page 28

Disaster Recovery Process

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 / Page 29

Disaster Recovery Process

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 1 BOXI Cluster Member 2 BOXI Start/Enable PROD services CMS (1 only) Cacheserver Connectionserver DeskICacheServer DeskIJobServer DeskIReportServer destinationserver Eventserver (1 only) Pageserver ListOfValuesJobserver Programserver RAS Reportjobserver ScoreCard_DF.jobserver Web_IntelligenceJobServer Web_IntelligenceReportServe Active ( IFRS & OFRS ) (1) Passive ( IFRS & OFRS ) (2,3,4)

Cluster Member 3 BOXI Cluster Member 4 BOXI

SAP 2008 / Page 30

Disaster Recovery Process

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

Test Production

Web Server 1 PROD

Web Server 2 PROD

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

Cluster Member 1 BOXI

Cluster Member 3 BOXI

Cluster Member 2 BOXI

Cluster Member 4 BOXI

SAP 2008 / Page 31

Disaster Recovery Process

SAP 2008 / Page 32

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 / Page 33

Backup Recovery Process

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/lib Command 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 / Page 34

Backup Recovery Process

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 / Page 35

Backup Recovery Process

Backup Recovery Process What objects get exported

SAP 2008 / Page 36

Backup Recovery Process

Backup Recovery Process Manually

STOP Services

STOP Database Processes

Backup the FRS and CMS at the SAME time HOT vs Cold backups

SAP 2008 / Page 37

Backup Recovery Process

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 / Page 38

Backup Recovery Process

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 Service The 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 Service The 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 / Page 39

Backup Recovery Process

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" "\\DENL-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 / Page 40

Backup Recovery Process

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 / Page 41

Backup Recovery Process

Backup Recovery Process

Document logs, execution times and sql backups

SAP 2008 / Page 42

Backup Recovery Process

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

SAP 2008 / Page 43

Thank you!

QUESTIONS

SAP 2008 / Page 44