boebackupanddrsvcsguide
TRANSCRIPT
Recovery ServicesBackup and Disaster Recovery XI
Darrin Joncas, Advanced Services GroupApril 8, 2008
© SAP 2008 / Page 2
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 / Page 3
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 / Page 4
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 / Page 5
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 6
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 7
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 8
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 9
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 / Page 10
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 / Page 11
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 12
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 13
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 / Page 14
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 / Page 15
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 16
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 17
Disaster Recovery Process
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 / Page 18
Disaster Recovery Process
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 / Page 19
Disaster Recovery Process
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 / Page 20
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
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 / Page 21
Disaster Recovery Process
Disaster Recovery Process (VISO) – Diagram it out
© SAP 2008 / Page 22
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 23
Disaster Recovery Process
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 / Page 24
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 4
(BOXI)
Cluster Member 5
(BOXI)
Cluster Member 6
(BOXI)
Change CCM to point to DR
ODBCODBCCMS ODBCAUDIT ODBCKPIODBCOTHER
© SAP 2008 / Page 25
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.)
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 / Page 26
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” 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 / Page 27
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 28
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)
Cluster Member 6
(BOXI)
Stop/disable 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 / Page 29
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 30
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 1BOXI
Cluster Member 2BOXI
Cluster Member 4BOXI
Start/Enable PROD servicesCMS (1 only)Cacheserver
ConnectionserverDeskICacheServer
DeskIJobServerDeskIReportServerdestinationserver
Eventserver (1 only)Pageserver
ListOfValuesJobserverProgramserver
RASReportjobserver
ScoreCard_DF.jobserverWeb_IntelligenceJobServer
Web_IntelligenceReportServeActive ( IFRS & OFRS ) (1)
Passive ( IFRS & OFRS ) (2,3,4)
Cluster Member 3BOXI
© SAP 2008 / Page 31
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
Your CMS DB and FRS FileStore are replicated and are aware of the other
Cluster Member 1BOXI
Cluster Member 2BOXI
Cluster Member 4BOXI
Cluster Member 3BOXI
Web Server 1PROD
Web Server 2PROD
Test Production
© SAP 2008 / Page 32
Disaster Recovery Process
© SAP 2008 / Page 33
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 34
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/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 / Page 35
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 36
Backup Recovery Process
Backup Recovery Process What objects get exported
© SAP 2008 / Page 37
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 38
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 39
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 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 / Page 40
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" "\\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 / Page 41
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 42
Backup Recovery Process
Backup Recovery Process Document logs,
execution times and sql backups
© SAP 2008 / Page 43
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 44
QUESTIONS
Thank you!