41 Managing WebCenter Portal Backup, Recovery, and Cloning

This chapter describes techniques and tools for backing up and restoring WebCenter Portal installations.

This chapter includes the following topics:

Permissions:

The content of this chapter is intended for system administrators.

For more information on which roles and permissions are required to deploy portals, templates, assets, connections, and extensions, see Section 39.6, "Permissions Required to Perform WebCenter Portal Life Cycle Operations."

See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."

41.1 Understanding WebCenter Portal Backup and Recovery

To recover data from disasters, such as the loss of database hardware, inadvertent removal of data from file or database, it is important to back up individual portals as well as the entire WebCenter Portal instance on a frequent basis. The frequency of your backups depend on how often the underlying information stored by WebCenter Portal changes in your particular environment, and how much time and amount of information could acceptably be lost. Incremental or partial backups may be applied where the data is critical to the business and must be restored due to a failure.

WebCenter Portal provides various backup options. Administrators can back up:

Note:

This chapter only describes techniques for backing up and restoring WebCenter Portal data. For information about Oracle Fusion Middleware backup and recovery strategies, see the "Advanced Administration: Backup and Recovery" section in Administrator's Guide.

41.2 Comparing Back up, Recovery, and Migration Tools for WebCenter Portal

Table 41-1 compares the various tools available to back up and restore WebCenter Portal or migrate WebCenter Portal to another target.

Table 41-1 Backup, Restore, and Migration Tools for WebCenter Portal


 Backup and Restore Backup and Restore Scripts Migration / Backup

Portals / Portal Templates Full WebCenter Portal Install WebCenter Portal Only

How to execute

WLST commands:

exportWebCenterPortals

exportWebCenterPortalTemplates

importWebCenterPortals

Customizable scripts based on:

master_script.sh, wlst_script.py, backup.properties, restore.properties

WLST commands:

exportWebCenterApplication

importWebCenterApplication

Prerequisites

WebCenter Portal must be installed, fully configured, and running on the target.

WebCenter Portal must be installed, fully configured, and running on the target.

WebCenter Portal must be installed, fully configured, and running on the target.

When to use

Use to back up and restore individual portals, portal hierarchies, and portal templates.

Useful if only one or two portals or portal templates are corrupt.

Use to restore WebCenter Portal from a nightly/weekly backup that was previously taken using a backup script (in case of corruption).Use to restore configuration in adf-config.xml, connections.xml, and credentials in /metadata/security/data/credentials.

Use to completely restore an entire WebCenter Portal installation on a new machine or WebLogic Server instance that is already installed and configured for Oracle WebCenter Portal.

Useful in a stage-to-production setup, where the production instance is installed and configured, and you want to copy WebCenter Portal on the stage instance (containing multiple portals, shared assets, security, and so on) to the target for the first time.

Suitable for multi-site portals that use a large number of shared assets or other global artifacts that must be moved to the target in a single step.

Not recommended for restoring a corrupt WebCenter Portal instance.

What is backed up / migrated

Portal-level customizations and user customizations for the portal.

Portal-level task flow customizations, portal-level task flow instance customizations, and user customizations for portal level task flow instances.

Portal content and portal data.

Portal security permissions and roles.

For details, see:

Section 40.1.2.1, "Understanding Portal Archives"

Section 40.1.3, "Deploying Portal Hierarchies"

Section 40.2, "Deploying Portal Templates"

MDS metadata for all tools and services, such as discussions, announcements, events, portlets, activities, tags, worklists, and so on.

Customizations of task flows, portlets, system pages, shared assets.

Security roles and permissions for all portals and for global artifacts, as well as user-role assignments. Users and audit data are also migrated.

Data stored in the WEBCENTER and MDS database schemas.

Optionally, data stored in other schemas such as DISCUSSIONS, DISCUSSIONS_CRAWLER, ACTIVITIES, PORTLET, OCS, and so on.

MDS metadata for all tools and services, such as discussions, announcements, events, portlets, activities, tags, worklists, and so on.

Customizations of task flows, portlets, system pages, shared assets.

Security roles and permissions for all portals and for global artifacts, as well as user-role assignments

Data stored in the WEBCENTER database schema for activity streams, portal events, feedback, lists, links, message boards, people connections, profiles, polls, surveys, and tags.

What is not backed up / migrated

Application-level information, such as, shared assets, global customizations, and the Home portal.

WebCenter Portal domain.

Data stored on other back-end systems, such as the content server, discussions server, BPEL server, mail servers, and so on.

WebCenter Portal connections to WSRP producers, PDK-Java producers, discussions servers, and so on. For details, see Section 40.1.2.1.3, "Understanding Connection Property Files."

Application-level settings stored in adf-config.xml (domain/MDS)

Credentials (metadata/security/data/credentials).

WebCenter Portal domain.

Pros

Relatively quick as only specific portals or portal templates are backed up and restored.

Allows more granular control over what is backed up and restored.

Most efficient when only a few portals are corrupt.

Simple, extensible, and reliable way to regularly back up data owned by WebCenter Portal.

Multiple, granular backup archives generated rather than a single large archive containing everything.11.1.1

MDS data, WEBCENTER database data, customizations, and security captured in a single step.

Simple to use and quicker than using four separate commands.

Cons

Cannot back up shared assets or the Home portal.

Database schemas WEBCENTER and MDS must be restored together. If not, data may become out-of-sync.

If restoring additional schemas, such as OCS, you must restore them at the same time and from the same point to maintain data integrity.

Incremental backup/restore is not supported.

Domain configuration is not included in the backup script so you must back up the domain separately. See the "Backup and Recovery Recommendations for Oracle WebLogic Server" section in Administrator's Guide.

Not recommended if you want to restore on a different instance with different back-end servers configured.

Requires a lot of internal processing.

Native tools are not used to extract data from the database.

Note:

Use Fusion Middleware test-to-production scripts to replicate a complete Fusion Middleware instance, installed and configured with WebCenter Portal, WebCenter Content, SOA Suite, BI, and so on, to one or more target environments. These scripts avoid you repeating complex install processes on multiple targets. For details, see the "Moving from a Test to a Production Environment" chapter in Administrator's Guide.

Test-to-production scripts are not recommended if the source WebCenter Portal installation has been used, that is, the customer has created metadata/data/security.

41.3 Backing Up Individual Portals

The back up process for one or more portals (or a portal hierarchy) is simple. You archive the portals and their content folders using the WLST command exportWebCenterPortals and then, if required, you back up any additional data that is stored for the portal in back-end components such as the discussions server.

The steps are as follows:

  1. Backup the portal to an export archive (PAR file).

    See Section 41.3.1, "Backing Up Portals Using WLST."

  2. Back up discussion data for the portal, if required.

    See Section 41.3.2, "Backing Up Discussion Data for a Portal."

  3. Back up other external data, if any.

    See Section 41.3.3, "Backing Up Other External Portal Data and Content."

The information in this section describes how to perform portal backups manually. If you need to back up frequently or want to set up a regular backup schedule, you can create a script that automates the backup process. For details, see Section 41.8, "Using Scripts to Back Up and Restore WebCenter Portal."

See also, Section 41.4, "Restoring Portals from a Backup."

Note:

The simultaneous backup of large numbers of portals is not recommended as, depending on server configuration, it may affect system performance. If a serious deterioration in performance is observed, break-down the backup/export process into several smaller groups.

41.3.1 Backing Up Portals Using WLST

Use the WLST command exportWebCenterPortals to back up a one or more portals to an archive (PAR file).

To find out what information is backed up inside a portal archive (PAR file) and what is not included, see Section 40.1.2.1, "Understanding Portal Archives."

Note:

Portal archives do not include shared assets or any information relating to the Home portal.

To prevent data loss, Oracle recommends that you:

  • Take portals offline during the backup process to prevent data conflict (offlineDuringExport=1)

  • Include portal content folders in the archive (exportPortalContent=1)

  • Include connection information in the archive (exportConnections=1)

    Note:

    Connection information is not portal specific. All connections configured for the source WebCenter Portal installation are exported. See also, Section 40.1.2.1.3, "Understanding Connection Property Files."

  • If a portal contains web service data controls or portlets, ensure that all associated web services or producers are up and accessible for the export to succeed.

For example, run the WLST command:

exportWebCenterPortals(appName='webcenter', fileName='BackupSalesPortals_31March2013.par', names='GlobalSales,MySales', offlineDuringExport=1, exportPortalContent=1, exportConnections=1)

The options that you set depends on your specific archive requirements. For command syntax, see the "exportWebCenterPortals" section in the WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

To restore the portal at a later date, see Section 41.4, "Restoring Portals from a Backup."

41.3.2 Backing Up Discussion Data for a Portal

Use the Discussions Server Admin Console to back up discussion data for a specific portal to a .zip file that you restore later on, if required. For details, see Section 40.8.1.1, "Exporting Portal Discussions to an Archive" and Section 40.8.1.2, "Importing Portal Discussions from an Archive."

See Section 41.4, "Restoring Portals from a Backup."

41.3.3 Backing Up Other External Portal Data and Content

Backup files do not include externally stored data that portals reference through Content Presenter and Site Studio (such as external web content and pages) so you must back up external data separately. Similarly, if your portal references documents and files outside of its own content folder, you must ensure that all storage areas used by the portal are backed up.

In both cases, refer to the appropriate product documentation for instructions on how to back up the external data and content.

41.4 Restoring Portals from a Backup

You can restore one or more portals from a backup archive using the WLST command importWebCenterPortals. Existing portals are deleted and replaced.

The steps are as follows:

  1. Restore the portal, by importing the portal backup archive (PAR file) on the target.

    See Section 41.4.1, "Restoring Portals from an Archive Using WLST."

  2. Restore discussion data for the portal, if required.

    See Section 41.4.2, "Restoring Discussions Data for Portal."

  3. Restore other external data and content, if any.

    See Section 41.4.3, "Restoring Other External Portal Data and Content."

The information in this section describes how to restore portal backups manually. If you prefer, you can create a script that automates the restoration process. For details, see Section 41.8, "Using Scripts to Back Up and Restore WebCenter Portal."

See also, Section 41.3, "Backing Up Individual Portals."

41.4.1 Restoring Portals from an Archive Using WLST

Use the WLST command importWebCenterPortals to restore one or more portals from an archive (PAR file).

To prevent data loss, Oracle recommends that you:

  • Import connections used by the portal that are missing on the target, for some reason, before you restore the portal.

    See, Section 40.6.2, "Importing New WebCenter Portal Connections from a File."

  • Take portals offline during portal restoration (forceOffline=1)

    Portal moderators can bring the portal back online after restoration.

  • Import all the information inside the archive (importCustomizations=1, importPortalContent=1, importSecurity=1, importData=1, importActivities=1).

  • If a portal contains web service data controls or portlets, all associated web services and producers must also be up and accessible for the import to succeed.

For example, run the WLST command:

importWebCenterPortals(appName='webcenter',
 fileName='BackupSalesPortals_31March2013.par', names='GlobalSales,MySales',
 parentPortal='Sales', importCustomizations=1, importPortalContent=1,
 importSecurity=1, importData=1, importActivities=1,
 overwrite=1, savePortals=1, forceOffline=1,
 importLog=/mybackups/RestoreSalesPortals_31march2013.log')

The options that you set depends on your specific requirements. For command syntax, see the "importWebCenterPortals" section in the WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

Note:

Portal-related data associated with some back-end components, specifically the discussions server, must be migrated after you export or import portals. See next topics, Section 41.4.2, "Restoring Discussions Data for Portal" and Section 41.4.3, "Restoring Other External Portal Data and Content."

41.4.2 Restoring Discussions Data for Portal

Use the Discussions Server Admin Console to restore discussion data for a particular portal from a backup .zip file. For details, see Section 40.8.1.2, "Importing Portal Discussions from an Archive" and Section 40.8.1.1, "Exporting Portal Discussions to an Archive."

See Section 41.3, "Backing Up Individual Portals."

41.4.3 Restoring Other External Portal Data and Content

If you backed up any external data or content that your portal uses, refer to the appropriate product documentation for instructions on how to restore information from your back ups, if required.

For example, you may want to regularly back up some externally stored data referenced by a portal through Content Presenter and Site Studio (such as external web content and pages) or documents that are stored outside the portal's own content folder.

41.5 Migrating Entire WebCenter Portal to Another Target

Using export and import, system administrators can migrate a WebCenter Portal instance to another target. This is useful in a stage-to-production setup, where the production instance is installed and configured and the entire WebCenter Portal instance on stage (containing multiple portals, shared assets, global artifacts, security, and so on) must be copied to the target for the first time.

You can also use the export and import utilities described in this section to back up global WebCenter Portal artifacts that are not owned by a particular portal, such as shared assets, business role pages, personal pages, and customized system pages.

This section includes the following topics:

Note:

To migrate Oracle WebCenter Portal content between Oracle WebCenter Content Server instances configured to use the FrameworkFolders component, you use the Archiver tool with the Configuration Migration Utility. Archiver provides support for moving content for Folders_g, but migration of only tables for FrameworkFolders.

In Archiver, if you want to move only the FrameworkFolders folder structure, export or import these tables using the Export Data (Table) tab: FolderFolders and FolderMetaDefault (also named FrameworkFoldersMetaDefaults). To additionally migrate table content, export or import the FolderFiles table also.

For information about Archiver, see the "Understanding System Migration and Archiving" chapter in Administering Oracle WebCenter Content.

41.5.1 Understanding Import and Export for WebCenter Portal

Using export and import, system administrators can migrate an entire WebCenter Portal instance between stage and production environments. You can export WebCenter Portal to a single export archive (.ear file) using WLST commands or Fusion Middleware Control, as shown in Figure 41-1.

The WebCenter Portal export archive (.ear file) contains several files, as listed in Table 41-2.

Table 41-2 Files in WebCenter Portal Export Archive EAR Files

Files Description

transport.mar

Metadata archive that captures MDS metadata and database schema data for an entire WebCenter Portal instance

policy-store.xml

Security policy information.

lifecycle.xml

Log file that records details about the export process, such as which MDS paths are exported.

The information in this file is useful if you want to compare two export archives or diagnose issues with the export and import process.

oracle-archive.xml

XML file containing version and compatibility information.

Figure 41-1 Migrating WebCenter Portal to Another Target

Description of Figure 41-1 follows
Description of ''Figure 41-1 Migrating WebCenter Portal to Another Target''

Information Included in a WebCenter Portal Archive

WebCenter Portal archives can include the following information that is stored in the metadata service (MDS) repository:

  • Portals and templates - All portals and portal templates

  • Assets - All shared assets and portal assets

  • Pages - All pages, including system pages, business role pages, personal pages, and portal pages

  • Global customizations - All global customizations applied to the application, system pages, other pages, assets, portlets, and task flows, that are stored in MDS.

  • User customizations - All user-defined customizations applied to the application, pages, and task flows, that are stored in MDS. Sometimes referred to as personalizations.

  • Application and service metadata - All application and service metadata stored in MDS (object definitions)

Note:

Some MDS customizations are optional on export, as illustrated in Figure 41-1. If you want to migrate all customizations you must set the export option "Include Customizations".

In addition, the WebCenter Portal archive (.ear file) can contain:

  • Tool/service data - Database data associated with those tools and services that store data in the WebCenter Portal schema (WEBCENTER)

    Data migration is optional. To migrate data you must set the export option "Include Services Data".

  • Security - All roles, permissions, and user role assignments:

    • application roles (and permissions assigned to each role)

    • users details and their application role assignments in the Home portal

    • individual portal members (and their role assignments in each portal)

Information Not Included in WebCenter Portal Archives

The WebCenter Portal archive (.ear file) does not include data associated with tools and services that do not store data in MDS or the WebCenter Portal database schema, such as analytics, activity graph, announcements, discussions, documents (on content server), instant messaging and presence (IMP), mail, pagelets, calendar events, personalizations, and worklists. To learn how to backup or move data associated with these tools and services, see Section 41.6, "Backing Up an Entire WebCenter Portal Installation."

Connection information is not included within the WebCenter Portal archive but you can export connection information configured in the source environment to a separate file and then deploy the connection information on the target. If some connection information, such as server names, ports, content management connections, and so on, varies between the two environments, you can isolate and modify the connection details before deploying the connection file. For details, see Section 40.6, "Moving Connections Details from Staging to Production."

Figure 41-2 lists in more detail exactly which information is always included, never included, or optional when you migrate WebCenter Portal to another target.

Figure 41-2 Information Exported and Imported with an Entire WebCenter Portal Instance

Description of Figure 41-2 follows
Description of ''Figure 41-2 Information Exported and Imported with an Entire WebCenter Portal Instance''

WebCenter Portal export and import can be performed using Fusion Middleware Control or WLST commands. For details, see:

41.5.2 Prerequisites for WebCenter Portal Export and Import

Before you export or import a WebCenter Portal instance, complete the following prerequisite tasks:

  1. Back up or migrate all the back-end components before you export or import WebCenter Portal.

    Migrate back-end components for the application, such as the LDAP identity store, credential store, policy store, discussions server, content server, portlet producers, and so on. For more information, see Section 41.6, "Backing Up an Entire WebCenter Portal Installation."

  2. Ensure that the database in which WebCenter Portal metadata and schema is stored is up and running otherwise export and import will not work.

  3. If your application contains web service data controls or portlets, ensure that all associated web services or producers are up and accessible for export and import to succeed.

  4. If you are migrating WebCenter Portal to another target, ensure that the tools and services configured in the target instance are a superset of the tools and services configured in the source instance. That is, the target must be configured with at least the same set of tools and services that the source is configured with. If this is not the case, the import operation fails.

  5. Import connections exported from the source on to the target.

    For more information, see Section 40.6, "Moving Connections Details from Staging to Production."

  6. Ensure that the users in both the source and target environment are identical.

    Important:

    If a shared identity store is not used, users must be migrated.

    Personal pages, that is, pages users create in the Home portal, are only migrated if the target and source applications both use the same LDAP identity store; this is because personal pages assignments are per user GUID.

    Verify that all users assigned the Administrator role in the source, exist in the target identity store. On import, users listed in WebCenter Portal's security policy are checked against the identity store that is configured for the domain. If a user is not found, any policies associated with that user are removed. See also, Section 31.4, "Moving the Administrator Account to an External LDAP Server."

  7. Back up the WEBCENTER and MDS database schemas on the target before importing a WebCenter Portal archive.

    See Section 41.6, "Backing Up an Entire WebCenter Portal Installation."

  8. Verify that the WebCenter Portal archive .ear file that you want to import was exported from WebCenter Portal 11.1.1.9.0.

    You cannot import archives from earlier versions directly into WebCenter Portal 11.1.1.9.0. If necessary, you must upgrade your source environment to 11.1.1.9.0 before you create the export archive. For details, "Patching Oracle WebCenter Portal" in Patching Guide.

41.5.3 Exporting WebCenter Portal to an Archive

This section describes how to export an entire WebCenter Portal instance using Fusion Middleware Control and WLST commands. WebCenter Portal is exported into a single export archive (.ear file) that you can save to your local file system or to a remote server file system.

Note:

For information about what the archive contains, see Section 41.1, "Understanding WebCenter Portal Backup and Recovery."

This section includes the following:

41.5.3.1 Exporting WebCenter Portal Using Fusion Middleware Control

System administrators can export an entire WebCenter Portal application using Fusion Middleware Control.

To export WebCenter Portal:

  1. In Fusion Middleware Control, navigate to the home page for WebCenter Portal.

    See Section 6.2, "Navigating to the Home Page for WebCenter Portal."

  2. From the WebCenter Portal menu, select Application Export (Figure 41-3).

    Figure 41-3 WebCenter Portal Menu - Application Export Option

    Description of Figure 41-3 follows
    Description of ''Figure 41-3 WebCenter Portal Menu - Application Export Option''

  3. Change the File Name for the export archive or accept the default name.

    To ensure uniqueness, the default .ear filename contains a unique ID—webcenter_wholeapp_ts_unique_ID.ear (Figure 41-4).

    Figure 41-4 Naming the Export Archive

    Description of Figure 41-4 follows
    Description of ''Figure 41-4 Naming the Export Archive''

  4. Set export options as required. For details, see Table 41-3.

    Table 41-3 WebCenter Portal: Application Export Options

    Field Description

    Include Tool/Service Data

    Select to export data stored in the WebCenter Portal database schema (WEBCENTER) for the following tools and services: activity streams, portal events, feedback, lists, links, message boards, people connections, profiles, polls, surveys, and tags. Notes data stored in the MDS repository is exported too.

    Always re-export list data if source and target list definitions do not match. Mis-match only occurs when a list definition exists on the target and it is subsequently changed in the source.

    If the application you are exporting contains a large amount of data, consider using the database export utilities to export (and import) the WebCenter Portal schema data instead. For details see, Section 41.6.1.2, "Back Up (Export) WebCenter Portal Schema Data" and Section 41.6.1.3, "Restore (Import) WebCenter Portal Data."

    Deselect this option if you do not want to export data stored in the WebCenter Portal database schema (WEBCENTER). For example, if you are migrating WebCenter Portal from a test environment to a stage or production environment and the test data is no longer required.

    Note: The export process does not export data associated with services that store data externally such as analytics, activity graph, announcements, discussions, documents (on content server), instant messaging and presence (IMP), mail, pagelets, calendar events, personalizations, and worklists. To learn how to back up or move data associated with these services, see documentation for that product. See also, Section 41.6, "Backing Up an Entire WebCenter Portal Installation."

    Include Customizations

    Select to export application-level (global) customizations and user-level customizations. For information about which customizations are optional on export, see Figure 41-2.

    If you deselect this option, WebCenter Portal is exported without any application-level or user-level customizations.

    See also, Figure 41-2, "Information Exported and Imported with an Entire WebCenter Portal Instance".

  5. Click Export.

  6. In the Download dialog (Figure 41-5), click Export to confirm that you want to go ahead.

    Figure 41-5 Downloading an Export Archive

    Description of Figure 41-5 follows
    Description of ''Figure 41-5 Downloading an Export Archive''

    Progress information is displayed during the export process. The application being exported cannot be accessed during export operations.

  7. When the export process is complete, specify a location for the export archive (.ear).

    Figure 41-6 Saving an Export Archive

    Description of Figure 41-6 follows
    Description of ''Figure 41-6 Saving an Export Archive''

    Select one of:

    • Download - Saves the export EAR file to your local file system.

      Your browser downloads and saves the archive locally. The actual download location depends on your browser set up.

    • Export to Server - Saves the export EAR file to a server location.

      When the Archive Location dialog displays (Figure 41-7), enter a suitable path for Server Location, for example, /tmp, and then click Save. The name of the EAR is not required here.

      Ensure that the server directory you specify has write permissions.

  8. Click Close to dismiss the Export window.

The export archive (.EAR) is saved to the specified location.

Check the diagnostic log file, WC_Spaces-diagnostic.log, for any warnings or errors reported during the export process. To view the log file, select the menu option WebCenter Portal > Logs > View Log Messages. For details, see Section 28.2.1, "Viewing and Configuring WebCenter Portal Logs."

See also, Section G.7, "Troubleshooting WebCenter Portal Import and Export."

41.5.3.2 Exporting WebCenter Portal Using WLST

Use the WLST command exportWebCenterApplication to export an entire WebCenter Portal instance.

The following example exports WebCenter Portal together with all customizations in MDS (both application-level and user-level customizations) and database data to a file named myAppExport.ear.

wls:/weblogic/serverConfig>exportWebCenterApplication(appName='webcenter', 
fileName='myAppExport.ear', exportCustomizations=1, exportData=1)

The following example exports a test WebCenter Portal instance. In this case, data created during testing (lists, events, links, tags, and so on) is not required in the target instance. The .ear file is saved to the location from which you run the WLST command:

wls:/weblogic/serverConfig>exportWebCenterApplication(appName='webcenter', 
fileName='myTestAppExport.ear', exportData=0)

For command syntax and examples, see the "exportWebCenterApplication" section in the WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

41.5.4 Importing a WebCenter Portal Archive

This section describes how to import an entire WebCenter Portal application using Fusion Middleware Control and WLST commands.

Before importing WebCenter Portal, ensure that you complete all the tasks listed in Section 41.5.2, "Prerequisites for WebCenter Portal Export and Import."

This section includes the following:

41.5.4.1 Importing WebCenter Portal Using Fusion Middleware Control

System administrators can import an entire WebCenter Portal instance using Fusion Middleware Control.

To import WebCenter Portal using Fusion Middleware Control:

  1. In Fusion Middleware Control, navigate to the home page for WebCenter Portal.

    See Section 6.2, "Navigating to the Home Page for WebCenter Portal."

  2. From the WebCenter Portal menu, select Application Import.

  3. In the WebCenter Portal Application Import page (Figure 41-8), specify the location of your WebCenter Portal archive (.ear).

    Figure 41-8 Application Import Page

    Description of Figure 41-8 follows
    Description of ''Figure 41-8 Application Import Page''

    Select one of the following:

    • Archive located on local file system - Enter the Archive Location. Alternatively, click Browse to locate the directory on the local file system where the .ear file is stored.

    • Archive located on server file system - Enter the Archive Location. Any shared location accessible from WebCenter Portal.

    The archive you select must contain an entire WebCenter Portal export—you cannot import individual portals or portal templates from here. Refer to Section 40.1.2.4, "Importing One or More Portals from an Archive" Section 40.1.2.4, "Importing One or More Portals from an Archive" for more information.

  4. Click Import.

  5. In the WebCenter Portal Application Import dialog, click Import.

    Figure 41-9 Application Import dialog

    Description of Figure 41-9 follows
    Description of ''Figure 41-9 Application Import dialog''

    Once the import is complete, a success message displays.

After importing an entire WebCenter Portal instance, log in to WebCenter Portal and verify the imported content. For details, see Section 41.5.4.3, "Verifying WebCenter Portal After Import."

41.5.4.2 Importing WebCenter Portal Using WLST

Use the WLST command importWebCenterApplication to import an entire WebCenter Portal instance from an archive. For command syntax and examples, see the "importWebCenterApplication" section in the WebLogic Scripting Tool Command Reference.

The following example imports WebCenter Portal from the export archive myAppExport.ear:

wls:/weblogic/serverConfig>importWebCenterApplication(appName='webcenter',fileName='myAppExport.ear')

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

Note:

After importing the WebCenter Portal instance, log in to WebCenter Portal and verify the imported content. For details, see Section 41.5.4.3, "Verifying WebCenter Portal After Import."

41.5.4.3 Verifying WebCenter Portal After Import

After importing WebCenter Portal from an archive you must:

  1. Restart the managed server (WC_Spaces) on which the newly imported WebCenter Portal instance is deployed.

    In a cluster environment, restart each managed server in the cluster. See also, Section 7.2, "Starting and Stopping Managed Servers for WebCenter Portal Application Deployments."

  2. Log in to WebCenter Portal and verify that all portals and portal templates are available as expected.

    If not, see Section G.7.3, "Portals and Portal Templates Not Available After Import."

  3. Initiate the Oracle Secure Enterprise Search crawler to index newly imported data.

    See also, Oracle Secure Enterprise Search Administrator's Guide.

41.6 Backing Up an Entire WebCenter Portal Installation

It is important to back up your entire WebCenter Portal installation on a frequent basis to avoid data loss due to database hardware failure or inadvertent removal of data from file or database.

This section outlines the steps required to completely back up all portals in the portal server, all database data, MDS, as well as data stored on other back-end servers. The backup process generates multiple, backup archives rather than a single large archive containing everything which facilitates a granular restore process.

The steps are as follows:

  1. Back up all data in the WebCenter Portal schema.

    See Back Up (Export) WebCenter Portal Schema Data.

  2. Back up all data in the MDS schema.

    See Back Up (Export) All MDS Schema Data.

  3. Back up all data for Content Server.

    See Backing Up and Restoring All WebCenter Content Data.

  4. Back up all discussions server data.

    See Backup (Export) All Discussions Schema Data.

  5. Back up other schema data stored for WebCenter Portal.

    See Backing up and Restoring Other Schema Data (ACTIVITIES and PORTLET).

  6. Back up data for portlet producers used by WebCenter Portal.

    See Backing Up and Restoring Portlet Producer Metadata.

  7. Back up pagelet producer metadata.

    See Backing Up and Restoring Pagelet Producer Metadata.

  8. Back up activity graph and analytics metadata.

    See Backing Up and Restoring Activity Graph and Analytics Metadata.

  9. Back up personalization data.

    See Backing Up and Restoring Personalization Metadata.

  10. Back up security stores.

    See Backing Up and Restoring LDAP Identity Store, Backing Up and Restoring Policy Stores (LDAP and Database) and Backing Up and Restoring Credential Stores (LDAP and Database).

  11. Back up the WebLogic domain hosting WebCenter Portal.

    See Backing Up and Restoring a WebCenter Portal Domain.

  12. Back up Audit configuration.

    See Backing Up and Restoring Audit Repository Configuration.

The information in this section describes how to back up manually. If you need to back up frequently or want to set up a regular backup schedule, you can create a script that automates the backup process. For details, see Section 41.8, "Using Scripts to Back Up and Restore WebCenter Portal."

41.6.1 Backing up and Restoring All WebCenter Portal Schema Data

WebCenter Portal's database schema (WEBCENTER) stores data for various tools and services including activity streams, portal events, feedback, lists, links, message boards, people connections, profiles, polls, surveys, and tags.

This section includes the following topics:

41.6.1.1 Prerequisites

If you are backing up or restoring an Oracle database schema, use setenv or export to set the following environment variables before backing up or restoring schema data:

  • ORACLE_HOME - Database home

  • ORACLE_SID - Service ID for the schemas

  • TNS_ADMIN - Set to ORACLE_HOME/network/admin

41.6.1.2 Back Up (Export) WebCenter Portal Schema Data

To back up WEBCENTER schema data, use the appropriate utility for your database:

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in Example 41-1, "Exporting WEBCENTER Schema Data".

    For detailed expdp command information, see Oracle Database Utilities guide.

  • For non-Oracle databases, refer to the manufacturer's documentation.

Example 41-1 Exporting WEBCENTER Schema Data

sqlplus "sys/password as sysdba"
create or replace directory mydmpdirectory as
'full_path_to_directory_on_file_system';
GRANT read,write ON directory mydmpdirectory TO public;
exit;

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=webcenterportal.dmp SCHEMAS=srcprefix_WEBCENTER
 EXCLUDE=STATISTICS NOLOGFILE=Y

Where:

  • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's schema (WEBCENTER) is installed.

  • password is the password for the system database user.

  • serviceid is the unique SID for the database. For example, mydb1234.

  • directory is the location on the database machine where the dump file will be created.

  • dumpfile is the name of the file that will contain the exported data.

  • SCHEMAS identifies the target schema to be imported. Schema names include the RCU suffix that was used during installation (_WEBCENTER), along with a user supplied prefix. For example, DEV_WEBCENTER.

  • EXCLUDE=STATISTICS specifies not to export statistics for the tables.

  • NOLOGFILE=Y Suppresses the creation of a log file.

See also, Section 41.6.1.3, "Restore (Import) WebCenter Portal Data."

41.6.1.3 Restore (Import) WebCenter Portal Data

To restore WEBCENTER schema data from a backup, use the appropriate utility for your database:

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in Example 41-2 or Example 41-3.

    For detailed impdp command information, see Oracle Database Utilities guide.

  • For non-Oracle databases, refer to the manufacturer's documentation.

To restore the WEBCENTER schema on an Oracle database:

  1. Shut down the target WebCenter Portal instance.

  2. Go to DB_ORACLE_HOME/bin of the database where the WEBCENTER schema is installed, connect to the database using sqlplus as sysdba and run the following commands:

    DB_ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
create or replace directory dmpdir as 'mydmpdirectory';
GRANT read,write ON directory dmpdir TO public;

  3. Do one of the following:

    • If schema names on the source and target match:

      drop user tgtprefix_WEBCENTER cascade;
exit;

    • If schema names on the source and target are different:

      drop user tgtprefix_WEBCENTER cascade;
create user tgtprefix_WEBCENTER identified by password default tablespace
tgtprefix_IAS_WEBCENTER temporary tablespace name_IAS_TEMP;
grant connect,resource to tgtprefix_WEBCENTER;
exit;

    Where:

    • tgtprefix_WEBCENTER is the user name. This is the RCU suffix that was used during installation, _WEBCENTER, along with a user supplied prefix. For example, DEV_WEBCENTER.

    • password is the password for the target user.

    • tgtprefix_IAS_WEBCENTER identifies the default tablespace. For example, the RCU suffix that was used during installation, IAS_WEBCENTER, along with a user supplied prefix. For example, DEV_IAS_WEBCENTER.

    • name_IAS_TEMP identifies the temporary tablespace. For example, DEV_IAS_TEMP.

  4. Run the import tool as described in Example 41-2 or Example 41-3.

    Example 41-2 Importing WebCenter Portal Schema Data (Source and Target Schema Names Match)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=webcenterportal.dmp SCHEMAS=tgtprefix_WEBCENTER

    Example 41-3 Importing WebCenter Portal Schema Data (Source and Target Schema Names Different)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=webcenterportal.dmp 
 remap_schema=srcprefix_WEBCENTER:tgtprefix_WEBCENTER
 remap_tablespace=source_tablespace:target_tablespace exclude=user
 TABLE_EXISTS_ACTION=REPLACE

    Where:

    • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's schema (WEBCENTER) is installed.

    • password is the password for the system database user.

    • serviceid is the unique SID for the database. For example, mydb1234.

    • directory is the location on the database machine where the dump file is located.

    • dumpfile is the name of the file that contains data to be imported.

    • SCHEMAS identifies the target schema to be imported. Schema names include the RCU suffix that was used during installation (_WEBCENTER), along with a user supplied prefix. For example, DEV_WEBCENTER.

      Use this parameter when schema names on the source and target match. For example, both schemas are named DEV_WEBCENTER.

    • REMAP_SCHEMA identifies the source and target schemas. Use this parameter when schema names on the source and target are different. Schema names include the RCU suffix that was used during installation, _WEBCENTER, along with the user supplied prefix. For example, DEV_WEBCENTER.

    • REMAP_TABLESPACE identifies the source and target tablespace. Remaps all objects selected for import with persistent data in the source tablespace to be created in the target tablespace. For example, source_tablespace:target_tablespace.

    • TABLE_EXISTS_ACTION=REPLACE drops the current table and creates the table as it is in the dump file.

41.6.2 Backing Up and Restoring All MDS Schema Data

The MDS schema contains customization metadata and data for WebCenter Portal.

This section includes the following topics:

41.6.2.1 Prerequisites

If you are backing up or restoring an Oracle database schema, use setenv or export to set the following environment variables before backing up or restoring schema data:

  • ORACLE_HOME - Database home

  • ORACLE_SID - Service ID for the schemas

  • TNS_ADMIN - Set to ORACLE_HOME/network/admin

Note:

For these backup (export) and restore (import) procedures to work, the schema names on the source and target must match. For example, both schemas must be named DEV_MDS.

41.6.2.2 Back Up (Export) All MDS Schema Data

To back up MDS data, use the appropriate utility for your database:

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in Example 41-4, "Exporting MDS Schema Data".

    For detailed expdp command information, see Oracle Database Utilities guide.

  • For non-Oracle databases, refer to the manufacturer's documentation.

Example 41-4 Exporting MDS Schema Data

sqlplus "sys/password as sysdba"
create or replace directory mydmpdirectory as
'full_path_to_directory_on_file_system';
GRANT read,write ON directory mydmpdirectory TO public;
exit;

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=mds.dmp SCHEMAS=srcprefix_MDS
 EXCLUDE=STATISTICS NOLOGFILE=Y

Where:

  • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's MDS schema is installed.

  • password is the password for the system database user.

  • serviceid is the unique SID for the database. For example, mydb1234.

  • directory is the location on the database machine where the dump file will be created.

  • dumpfile is the name of the file that will contain the exported data.

  • SCHEMAS is the schema to be exported. Include the RCU suffix that was used during installation (_MDS), along with a user supplied prefix. For example, DEV_MDS.

    Schema names on the source and target must match. For example, both schemas must be named DEV_MDS.

  • EXCLUDE=STATISTICS specifies not to export statistics for the tables.

  • NOLOGFILE=Y Suppresses the creation of a log file.

See also, Section 41.6.2.3, "Restore (Import) MDS Schema Data."

41.6.2.3 Restore (Import) MDS Schema Data

To restore MDS schema data from a backup, use the appropriate utility for your database:

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in Example 41-5, "Importing MDS Schema Data".

    For detailed impdp command information, see Oracle Database Utilities guide.

  • For non-Oracle databases, refer to the manufacturer's documentation.

To restore the MDS schema on an Oracle database:

  1. Shut down the target MDS instance.

  2. Go to DB_ORACLE_HOME/bin of the database where the MDS schema is installed, connect to the database using sqlplus as sysdba and run the following commands:

    DB_ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
create or replace directory dmpdir as 'mydmpdirectory';
GRANT read,write ON directory dmpdir TO public;

  3. Drop the MDS schema and exit sqlplus:

    drop user tgtprefix_MDS cascade;
exit;

  4. Run the import tool as described in Example 41-5, "Importing MDS Schema Data".

    Example 41-5 Importing MDS Schema Data

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=mds.dmp SCHEMA=tgtprefix_MDS

    Where:

    • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's MDS schema is installed.

    • password is the password for the system database user.

    • serviceid is the unique SID for the database. For example, mydb1234.

    • directory is the location on the database machine where the dump file is located.

    • dumpfile is the name of the file that contains data to be imported.

    • SCHEMAS is the schema to be imported. Include the RCU suffix that was used during installation (_MDS), along with the user supplied prefix. For example, DEV_MDS.

      Schema names on the source and target must match. For example, both schemas must be named DEV_MDS.

41.6.3 Backing Up and Restoring All WebCenter Content Data

To fully back up Oracle WebCenter Content, you must back up data the WebCenter Content database schema (OCS), back up all the WebCenter Content native (vault) and web-viewable (weblayout) files, and also back up other configuration data. For details, see the "Backup and Recovery Recommendations for Oracle WebCenter Content" section in Administrator's Guide.

Optionally, you can back up the root folder for a WebCenter Portal instance (or specific Portal Framework application) to a separate archive. A root folder backup may be useful if the folder becomes corrupt or you want to migrate the entire the folder to another target. For detailed instructions, see the "System Migration and Archiving" section in Administering Oracle WebCenter Content.

Note:

Consider the following when restoring or migrating root folders for WebCenter Portal:

  • Security data is not archived with the root folder

  • Root folder migration must take place before you start WebCenter Portal for the first time

    (WebCenter Portal only). When you start WebCenter Portal for the first time a root folder is automatically created for WebCenter Portal on the Content Server. You cannot later overwrite this folder with a root folder archive exported from a different WebCenter Portal instance as internal root folder IDs will not match. If you plan to migrate root folder content, you must do so before the WebCenter Portal instance starts up for the first time.

  • Folder ID "counter" on source and target must match

    Every time you create a folder on Content Server, a folder ID counter increments by one. If the counter on the source and target is not in sync you may experience issues when you try to create folders on the target after an import operation. For example, if the folder ID counter on the target is on 4 when you import folders with IDs 5,6,7,8, you will see an error the next time you try to create a folder on the target as it will attempt to create a folder with an ID of 5. The only workaround is to manually alter the counter table on the target using SQL.

As root folder backups are not appropriate for every restoration use case, Oracle recommends full WebCenter Content database schema back ups for your primary back up/restore strategy.

After restoring WebCenter Content data, log in to WebCenter Portal and open any portal that utilizes document-related task flows. Verify that document services are enabled in that portal and that imported folders are available as expected.

41.6.4 Backing up and Restoring Discussion Schema Data

Discussions and announcements store information in two database schemas:

  • DISCUSSIONS: stores discussions and announcements data

  • DISCUSSIONS_CRAWLER: enables Oracle Secure Enterprise Search (SES) to crawl the discussions server

This section includes the following topics:

41.6.4.1 Prerequisites

If you are backing up or restoring an Oracle database schema, use setenv or export to set the following environment variables before backing up or restoring schema data:

  • ORACLE_HOME - Database home

  • ORACLE_SID - Service ID for the database

  • TNS_ADMIN - Set to ORACLE_HOME/network/admin

41.6.4.2 Backup (Export) All Discussions Schema Data

To back up all discussions schema data, use the appropriate utility for your database:

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in Example 41-6, "Exporting Discussions Schema Data".

    For detailed expdp command information, see Oracle Database Utilities guide.

  • For non-Oracle databases, refer to the manufacturer's documentation.

Notes:

Example 41-6 Exporting Discussions Schema Data

sqlplus "sys/password as sysdba"
create or replace directory mydmpdirectory as 'full_path_to_directory_on_file_system';
GRANT read,write ON directory mydmpdirectory TO public;
exit;

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" directory=mydmpdirectory dumpfile=discussions.dmp SCHEMAS=srcprefix_DISCUSSIONS,srcprefix_DISCUSSIONS_CRAWLER EXCLUDE=STATISTICS NOLOGFILE=Y

Where:

  • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's discussions schemas are installed.

  • password is the password for the system database user.

  • serviceid is the unique SID for the database. For example, mydb1234.

  • directory is the location on the database machine where the dump file will be created.

  • dumpfile is the name of the file that will contain the exported data.

  • SCHEMAS identifies the schemas to be exported. Include the RCU suffix that was used during installation (_DISCUSSIONS and _DISCUSSIONS_CRAWLER), along with a user supplied prefix. For example, DEV_DISCUSSIONS.

    To export data from both schemas, separate each schema name with a comma.

  • EXCLUDE=STATISTICS specifies not to export statistics for the tables.

  • NOLOGFILE=Y Suppresses the creation of a log file.

See also, Section 41.6.4.3, "Restore (Import) Discussions Schema Data."

41.6.4.3 Restore (Import) Discussions Schema Data

To restore discussions schema data from a backup, use the appropriate utility for your database:

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in Example 41-7 or Example 41-8.

    For detailed impdp command information, see Oracle Database Utilities guide.

  • For non-Oracle databases, refer to the manufacturer's documentation.

To restore DISCUSSIONS and DISCUSSIONS_CRAWLER schemas on an Oracle database:

  1. Shut down the target discussions server.

  2. Go to DB_ORACLE_HOME/bin of the database where the DISCUSSIONS and DISCUSSIONS_CRAWLER schema is installed, connect to the database using sqlplus as sysdba and run the following commands:

    DB_ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
create or replace directory dmpdir as 'mydmpdirectory';
GRANT read,write ON directory dmpdir TO public;

  3. Do one of the following:

    • If schema names on the source and target match:

      drop user tgtprefix_DISCUSSIONS cascade;
drop user tgtprefix_DISCUSSIONS_CRAWLER cascade;
exit;

    • If schema names on the source and target are different:

      drop user tgtprefix_DISCUSSIONS cascade;
drop user tgtprefix_DISCUSSIONS_CRAWLER cascade;
create user tgtprefix_DISCUSSIONS identified by password default tablespace
tgtprefix_IAS_DISCUSSIONS temporary tablespace name_IAS_TEMP;
grant connect,resource to tgtprefix_DISCUSSIONS
exit;

    Where:

    • tgtprefix_DISCUSSIONS is the user name. This is the RCU suffix that was used during installation, _DISCUSSIONS, along with a user supplied prefix. For example, DEV_DISCUSSIONS.

    • password is the password for the target user.

    • tgtprefix_IAS_DISCUSSIONS identifies the default tablespace. For example, the RCU suffix that was used during installation, IAS_DISCUSSIONS, along with a user supplied prefix. For example, DEV_IAS_DISCUSSIONS.

    • name_IAS_TEMP identifies the temporary tablespace. For example, DEV_IAS_TEMP.

  4. Run the import tool as described in Example 41-7 or Example 41-8.

    Example 41-7 Importing Discussions Schema Data (Source and Target Schema Names Match)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=discussions.dmp
 SCHEMAS=tgtprefix_DISCUSSIONS,tgtprefix_DISCUSSIONS_CRAWLER

    Example 41-8 Importing Discussions Schema Data (Source and Target Schema Names Different)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=discussions.dmp 
 remap_schema=srcprefix_DISCUSSIONS:tgtprefix_DISCUSSIONS
 remap_schema=srcprefix_DISCUSSIONS_CRAWLER:tgtprefix_DISCUSSIONS_CRAWLER
 remap_tablespace=source_tablespace:target_tablespace exclude=user
 TABLE_EXISTS_ACTION=REPLACE

    Where:

    • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's discussions schemas are installed.

    • password is the password for the system database user.

    • serviceid is the unique SID for the database. For example, mydb1234.

    • directory is the location on the database machine where the dump file is located.

    • dumpfile is the name of the file that contains data to be imported.

    • SCHEMAS identifies the schema (or schemas) to be imported. Include the RCU suffix that was used during installation (_DISCUSSIONS and _DISCUSSIONS_CRAWLER), along with a user supplied prefix. The DISCUSSIONS and DISCUSSIONS_CRAWLER schemas have the same user supplied prefix, for example, DEV_DISCUSSIONS and DEV_DISCUSSIONS_CRAWLER.

      Use this parameter when schema names on the source and target match. For example, schemas in the source and target database are both named DEV_DISCUSSIONS and DEV_DISCUSSIONS_CRAWLER.

    • REMAP_SCHEMA identifies the source and target schemas. Use this parameter when schema names on the source and target are different. Schema names include the RCU suffix that was used during installation, _DISCUSSIONS, along with the user supplied prefix. For example, DEV_DISCUSSIONS.

      The DISCUSSIONS and DISCUSSIONS_CRAWLER schemas have the same user supplied prefix.

    • REMAP_TABLESPACE identifies the source and target tablespace. Remaps all objects selected for import with persistent data in the source tablespace to be created in the target tablespace. For example, source_tablespace:target_tablespace.

    • TABLE_EXISTS_ACTION=REPLACE drops the current table and creates the table as it is in the dump file.

41.6.5 Backing up and Restoring Other Schema Data (ACTIVITIES and PORTLET)

In addition to the schemas mentioned in the previous topic (WEBCENTER, MDS, DISCUSSIONS, and DISCUSSIONS_CRAWLER), WebCenter Portal can store data is several other schemas:

  • ACTIVITIES Stores activity graph and analytics data

  • PORTLET Stores portlet and pagelet data

The backup and restore procedures are common for all schemas. Use the appropriate utility for your database:

Prerequisites (Oracle Database)

If you are backing up or restoring an Oracle database schema, use setenv or export to set the following environment variables before backing up or restoring schema data:

  • ORACLE_HOME - Database home

  • ORACLE_SID - Service ID for the schemas

  • TNS_ADMIN - Set to ORACLE_HOME/network/admin

Exporting Schema Data (Oracle Database)

Example 41-9 shows a sample expdp command for exporting Oracle database schema data. Replace schemadump.dmp and SCHEMA_NAME to match the schema you want to export.

Example 41-9 Exporting Schema Data (Oracle Database)

sqlplus "sys/password as sysdba"
create or replace directory mydmpdirectory as
'full_path_to_directory_on_file_system';
GRANT read,write ON directory mydmpdirectory TO public;
exit;

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=schemadump.dmp SCHEMAS=srcprefix_SCHEMA_NAME
 EXCLUDE=STATISTICS NOLOGFILE=Y

Where:

  • DB_ORACLE_HOME is the directory in which the database schema is installed.

  • password is the password for the system database user.

  • serviceid is the unique SID for the database. For example, mydb1234.

  • directory is the location on the database machine where the dump file will be created.

  • dumpfile is the name of the file that will contain the exported data.

  • SCHEMAS is the schema (or schemas) to be exported. This is the RCU suffix that was used during installation (_SCHEMA_NAME), along with the user supplied prefix. For example, DEV_ACTIVITIES.

    If you want to export data from multiple schemas, separate each schema name with a comma.

  • EXCLUDE=STATISTICS specifies not to export statistics for the tables.

  • NOLOGFILE=Y suppresses the creation of a log file.

Importing Schema Data (Oracle Database)

Example 41-10 and Example 41-11 show sample impdp commands for importing schema data. Replace schemadump.dmp and SCHEMA_NAME to match the schema you want to import.

  1. Shut down the target WebCenter Portal instance.

  2. Go to DB_ORACLE_HOME/bin of the database where the schema is installed, connect to the database using sqlplus as sysdba and run the following commands:

    DB_ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
create or replace directory dmpdir as 'mydmpdirectory';
GRANT read,write ON directory dmpdir TO public;

  3. Do one of the following:

    • If schema names on the source and target match:

      drop user tgtprefix_SCHEMA_NAME cascade;
exit;

    • If schema names on the source and target are different:

      drop user tgtprefix_SCHEMA_NAME cascade;
create user tgtprefix_SCHEMA_NAME identified by password default tablespace
tgtprefix_IAS_SCHEMA_NAME temporary tablespace name_IAS_TEMP;
grant connect,resource to tgtprefix_SCHEMA_NAME;
exit;

    Where:

    • tgtprefix_SCHEMA_NAME is the user name. This is the RCU suffix that was used during installation, _SCHEMA_NAME, along with a user supplied prefix. For example, DEV_ACTIVITIES.

    • password is the password for the target user.

    • tgtprefix_IAS_SCHEMA_NAME identifies the default tablespace. For example, the RCU suffix that was used during installation, IAS_SCHEMA_NAME, along with a user supplied prefix. For example, DEV_IAS_ACTIVITIES.

    • name_IAS_TEMP identifies the temporary tablespace. For example, DEV_IAS_TEMP.

  4. Run the import tool as described in Example 41-10 or Example 41-11.

    Example 41-10 Importing Schema Data (Source and Target Schema Names Match)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=schemadump.dmp SCHEMAS=tgtprefix_SCHEMA_NAME

    Example 41-11 Importing Schema Data (Source and Target Schema Names Different)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\"
 directory=mydmpdirectory dumpfile=schemadump.dmp 
 remap_schema=srcprefix_SCHEMA_NAME:tgtprefix_SCHEMA_NAME
 remap_tablespace=source_tablespace:target_tablespace exclude=user
 TABLE_EXISTS_ACTION=REPLACE

    Where:

    • DB_ORACLE_HOME is the directory in which the database schema is installed.

    • password is the password for the system database user.

    • serviceid is the unique SID for the database. For example, mydb1234.

    • directory is the location on the database machine where the dump file is located.

    • dumpfile is the name of the file that contains data to be imported.

    • SCHEMAS is the schema (or schemas) to be imported. This is the RCU suffix that was used during installation (_SCHEMA_NAME), along with the user supplied prefix. For example, DEV_ACTIVITIES.

      Use this parameter when schema names on the source and target match. For example, both schemas must be named DEV_ACTIVITIES.

      If you want to export data from multiple schemas, separate each schema name with a comma.

    • REMAP_SCHEMA identifies the source and target schemas. Use this parameter when schema names on the source and target are different. Schema names include the RCU suffix that was used during installation, _SCHEMA_NAME, along with the user supplied prefix. For example, DEV_ACTIVITIES.

    • REMAP_TABLESPACE identifies the source and target tablespace. Remaps all objects selected for import with persistent data in the source tablespace to be created in the target tablespace. For example, source_tablespace:target_tablespace.

    • TABLE_EXISTS_ACTION=REPLACE drops the current table and creates the table as it is in the dump file.

41.6.6 Backing Up and Restoring LDAP Identity Store

External identity stores, such as Oracle Internet Directory, store data in the underlying database. For information on how to back up and restore database schema data for Oracle Internet Directory, see the "Backup and Recovery Recommendations for Oracle Internet Directory" section in Administrator's Guide.

If you are using a different LDAP identity store, refer to the appropriate backup and recovery documentation for that product.

41.6.7 Backing Up and Restoring Policy Stores (LDAP and Database)

Use the WLST command migrateSecurityStore to back up and then restore the policy store that is configured for WebCenter Portal or your Portal Framework application. In a production environment, Oracle recommends that policies are stored in LDAP or a database. File-based policy stores are not recommended.

Use migrateSecurityStore to:

  • Back up your LDAP or database-based policy store to a backup file

  • Restore your LDAP or database policy store from a backup file

For details, see the "Migrating Policies Manually" section in Securing Applications with Oracle Platform Security Services.

See also, the "migrateSecurityStore" section in WebLogic Scripting Tool Command Reference.

Note:

Security policy data is included when you use WebCenter Portal's export/import utilities (exportWebCenterApplication and importWebCenterApplication) to migrate WebCenter Portal to another instance so there is no need to manually migrate the policy store in this instance. For more information, see Section 41.5, "Migrating Entire WebCenter Portal to Another Target."

41.6.8 Backing Up and Restoring Credential Stores (LDAP and Database)

Use the WLST command migrateSecurityStore to back up and then restore the credential store that is configured for WebCenter Portal or your Portal Framework application. In a production environment, Oracle recommends that credentials are stored in LDAP or a database. File-based credential stores are not recommended.

Use migrateSecurityStore to:

  • Back up your LDAP or database-based credential store to a backup file

  • Restore your LDAP or database credential store from a backup file

For details, see the "Migrating Credentials with migrateSecurityStore" section in Securing Applications with Oracle Platform Security Services.

See also, "migrateSecurityStore" in WebLogic Scripting Tool Command Reference.

41.6.9 Backing Up and Restoring a WebCenter Portal Domain

For information on how to back up and restore your domain configuration, see the "Backup and Recovery Recommendations for Oracle WebLogic Server" section in Administrator's Guide.

41.6.10 Backing Up and Restoring Portlet Producer Metadata

Portlet producers can store registration handles and portlet preference data as metadata with the consumer application, that is, WebCenter Portal or a Portal Framework application. This section describes how to back up any portlet metadata that is stored by your application using the WLST command exportPortletClientMetadata and how to restore the portlet metadata using importPortletClientMetadata.

Note:

Portlet metadata is included when you use WebCenter Portal's export/import utilities (exportWebCenterApplication and importWebCenterApplication) to migrate WebCenter Portal to another instance so there is no need to manually migrate portlet producer metadata in this instance. For more information, see Section 41.5, "Migrating Entire WebCenter Portal to Another Target."

This section includes the following topics:

For information on how to back up portlet producer data stored on the database, see Section 41.6.5, "Backing up and Restoring Other Schema Data (ACTIVITIES and PORTLET)."

41.6.10.1 Backing Up (Exporting) Portlet Client Metadata

To export portlet client metadata and producer customizations and personalizations, for a single application, such as WebCenter Portal or a Portal Framework application, use the WLST command exportPortletClientMetadata. This command exports metadata for all the portlet producers used by the application. You cannot opt to export metadata for specific producers.

For detailed syntax and examples, see the "exportPortletClientMetadata" section in WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

41.6.10.2 Restoring (Importing) Portlet Client Metadata

To import portlet client metadata and producer customizations and personalizations, for WebCenter Portal or a Portal Framework application, use the WLST command importPortletClientMetadata.

Prerequisites:

  • The database in which the application metadata or schema is stored and the portlet producers must be up and running.

  • Use the WLST command exportPortletClientMetadata to export the portlet client metadata and producer customizations and personalizations to an .ear file, See also, Section 41.6.10.1, "Backing Up (Exporting) Portlet Client Metadata."

For detailed syntax and examples, see the "importPortletClientMetadata" section in WebLogic Scripting Tool Command Reference. See also, the "Metadata Services (MDS) Custom WLST Commands" section.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

41.6.11 Backing Up and Restoring Pagelet Producer Metadata

The pagelet producer stores configuration data and content in MDS. You can back up pagelet metadata to a separate archive using the exportMetadata and importMetadata WLST commands. For details, see Section 22.5, "Managing Import, Export, Backup and Recovery of Pagelet Producer Components."

41.6.12 Backing Up and Restoring Activity Graph and Analytics Metadata

Activity graph stores metadata definitions for mapping WebCenter Portal event data from analytics in MDS. You can back up activity graph metadata to a separate archive using the exportAGMetadata and importAGMetadata WLST commands. You can also back up provider configuration metadata, for a given provider, to an activity graph metadata definition file using the WLST command exportAGProviderConfiguration. For details, see Section 10.6, "Managing Activity Graph Schema Customizations."

To back up the entire ACTIVITIES database schema, see Section 41.6.5, "Backing up and Restoring Other Schema Data (ACTIVITIES and PORTLET)."

41.6.13 Backing Up and Restoring Personalization Metadata

Personalization files are stored in MDS. You can back up personalization data stored in MDS for WebCenter Portal or your Portal Framework application to an archive using the exportMetadata WLST command and restore personalization data from the archive, if required, using importMetadata.

To back up (export) personalization data in MDS:

exportMetadata(application='wcps-services', server='server_name',
 toLocation='archive_file_name', remote='true')

To restore (import) personalization data from an archive to MDS:

importMetadata(application='wcps-services', server='server_name',
 fromLocation='archive_file_name', remote='true')

For example:

exportMetadata(application='wcps-services', server='WC_Utilities',
 toLocation='/backup_11_11_2013/backupWCPS.zip', remote='true')

importMetadata(application='wcps-services', server='WC_Utilities',
 fromLocation='/backup_11_11_2013/backupWCPS.zip, remote='true')

41.6.14 Backing Up and Restoring Audit Repository Configuration

You can back up audit policies and audit repository configuration to a file using the exportAuditConfig and importAuditConfig WLST commands.

For detailed syntax and examples, see the "exportAuditConfig" and "importAuditConfig" sections in WebLogic Scripting Tool Command Reference.

41.7 Restoring an Entire WebCenter Portal Installation

This section describes how to restore your WebCenter Portal installation after some hardware failure or inadvertent removal of data from file or database. Use the steps in this section to completely restore an entire WebCenter Portal installation on a new machine or WebLogic Server instance that is already installed and configured for Oracle WebCenter Portal.

The steps in this section assume that the back-end servers and connections used in the restored instance are exactly the same as those configured prior to the restoration process.

Important:

Database schemas WEBCENTER and MDS must be restored together to ensure the data is in-sync.

If you need to restore additional schemas, such as OCS, you must restore them at the same time and from the same point to maintain data integrity.

The steps are as follows:

  1. Restore WebCenter Portal schema from a backup.

    See Restore (Import) WebCenter Portal Data.

  2. Restore MDS schema data from a backup.

    See Restore (Import) MDS Schema Data.

  3. (Optional) Restore Content Server data from a backup.

    See Backing Up and Restoring All WebCenter Content Data.

  4. (Optional) Restore discussion schema data from a backup.

    See Restore (Import) Discussions Schema Data.

  5. (Optional) Restore other schemas data for WebCenter Portal from a backup.

    See Backing up and Restoring Other Schema Data (ACTIVITIES and PORTLET).

  6. Restore security store data from backups.

    For details, see:

  7. (Optional) Restore connections for WebCenter Portal from a backup.

    See Importing New WebCenter Portal Connections from a File.

  8. (Optional) Restore audit configuration for WebCenter Portal from a backup.

    See Backing Up and Restoring Audit Repository Configuration.

  9. (Optional) Restore the WebLogic Server domain hosting WebCenter Portal from a backup.

    See Backing Up and Restoring a WebCenter Portal Domain.

  10. Restart, and verify restored

In some situations you may need to restore metadata associated with individual tools and services. In this case, refer to the following topic:

The information in this section describes how to restore manually. If you need to restore or migrate data frequently, you can create a script that automates the process. For details, see Section 41.8, "Using Scripts to Back Up and Restore WebCenter Portal."

41.8 Using Scripts to Back Up and Restore WebCenter Portal

Backing up your WebCenter Portal installation manually can take time. Using scripts to automate and schedule regular back ups is more efficient and saves a great deal of time. To help you get started, Oracle provides a sample backup script that you can customize to suit your installation and backup requirements.

For more information, read the following topics:

41.8.1 Understanding Backup and Restore Script Files

Oracle provides sample scripts to help automate your backup and recovery processes. The sample scripts back up and restore the following information:

  • Database schemas: Back up all the required schemas for WebCenter Portal.

  • Data in file stores: Back up and restore WebCenter Portal data stored in the WebCenter Content file system.

  • Security information: Back up and restore policy store, credential store, and audit configuration for WebCenter Portal.

Table 41-4 describes the sample scripts and files provided for backup and recovery:

Table 41-4 Sample Scripts and Files for Backup and Restore

Sample Scripts and Files Description Use to...

master_script.sh

Shell script that executes database export commands, archives WebCenter Content on the file system, and executes WLST export and import commands.

See Section 41.8.1.1, "master_script.sh."

Back up and restore

wlst_script.py

Python script that runs WLST commands for exporting and importing portlet and security metadata.

See Section 41.8.1.2, "wlst_script.py."

Back up and restore

backup.properties

Properties file that contains input parameters to back up WebCenter Portal databases and run WLST export commands in master_script.sh and wlst_script.py.

See Section 41.8.1.3, "backup.properties and restore.properties Files."

Back up only

restore.properties

Properties file that contains input parameters for master_script.sh and wlst_script.py that enable you to restore WebCenter Portal databases and run WLST import commands from backup files.

See Section 41.8.1.3, "backup.properties and restore.properties Files."

Restore only

The sample files are starter scripts for you to review and modify. Alternatively, you can create your own scripts from scratch, if preferred.

41.8.1.1 master_script.sh

master_script.sh is shown in Example 41-12.

This script can back up (export) WebCenter Portal data stored in the following database schemas:

  • WEBCENTER

  • MDS

  • DISCUSSIONS

  • DISCUSSIONS_CRAWLER

  • OCS

  • ACTIVITIES

  • PORTLET

During back up, the script executes an export database command expdp for each schema you want to back up:

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" directory=backup_directory dumpfile=dump_file_name.dmp SCHEMAS=prefix_SCHEMA_NAME EXCLUDE=STATISTICS NOLOGFILE=y

See Also:

The expdp database command for individual schemas are described in Section 41.6, "Backing Up an Entire WebCenter Portal Installation."

The script also exports or imports WebCenter Content native files (vault folder) and web-viewable files (weblayout folder) stored on the file system.

  • To back up WebCenter Content files stored on the file system, the script executes the following:

    tar cvf wcc_vault.tar WCP_ORACLE_HOME/ucm/vault

    tar cvf wcc_weblayout.tar WCP_ORACLE_HOME/ucm/weblayout

  • To restore WebCenter Content files on the target file system, the script executes the following:

    tar xvf wcc_vault.tar

    tar xvf wcc_weblayout.tar

Finally, the script calls the WLST command script wlst_script.py. For details, see Section 41.8.1.2, "wlst_script.py."

Example 41-12 Sample Script - master_script.sh

## master_script.sh
## Backs up or restores a WebCenter Portal installation
## Executes database export or import commands and a Python script containing WLST commands.
############ No User Input Required ########################################
# Reading the properties files for WebCenter Portal back up or restore...
PROPS_FILE=$1

exportimport=`sed '/^\#/d' $PROPS_FILE | grep 'OPERATION'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
dump_directory=`sed '/^\#/d' $PROPS_FILE | grep 'DATA_DIRECTORY'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_home=`sed '/^\#/d' $PROPS_FILE | grep 'DB_ORACLE_HOME'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_admin=`sed '/^\#/d' $PROPS_FILE | grep 'DB_ADMIN_USER'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_adminpwd=`sed '/^\#/d' $PROPS_FILE | grep 'DB_ADMIN_PASSWORD'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_sid=`sed '/^\#/d' $PROPS_FILE | grep 'DB_SID'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_connect_webcenter=`sed '/^\#/d' $PROPS_FILE | grep 'DB_CONNECT_WEBCENTER_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_connect_mds=`sed '/^\#/d' $PROPS_FILE | grep 'DB_CONNECT_MDS_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_connect_discussions=`sed '/^\#/d' $PROPS_FILE | grep 'DB_CONNECT_DISCUSSIONS_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_connect_ocs=`sed '/^\#/d' $PROPS_FILE | grep 'DB_CONNECT_OCS_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_connect_activities=`sed '/^\#/d' $PROPS_FILE | grep 'DB_CONNECT_ACTIVITIES_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
oracle_db_connect_portlet=`sed '/^\#/d' $PROPS_FILE | grep 'DB_CONNECT_PORTLET_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`

#Read schema information from the properties file.
src_webcenter_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_WEBCENTER_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
src_mds_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_MDS_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
src_ocs_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_OCS_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
src_discussions_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_DISCUSSIONS_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
src_discussions_crawler_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_DISCUSSIONS_CRAWLER_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
src_activities_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_ACTIVITIES_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
src_portlet_schema=`sed '/^\#/d' $PROPS_FILE | grep 'EXP_PORTLET_SCHEMA'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`


# Read WLST connection information from the properties file.
username=`sed '/^\#/d' $PROPS_FILE | grep 'WLST_ADMIN_USER'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
password=`sed '/^\#/d' $PROPS_FILE | grep 'WLST_ADMIN_PASSWORD'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
adminconsole=`sed '/^\#/d' $PROPS_FILE | grep 'WLST_ADMIN_CONSOLE'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
wlstlocation=`sed '/^\#/d' $PROPS_FILE | grep 'WLST_LOCATION'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
wlstscriptfile=`sed '/^\#/d' $PROPS_FILE | grep 'WLST_SCRIPT_LOCATION'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
wcpServer=`sed '/^\#/d' $PROPS_FILE | grep 'WCP_SERVER_NAME'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
jpsConfigFile=`sed '/^\#/d' $PROPS_FILE | grep 'JPS_CONFIG_FILE'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
sourceJpsContextPolicy=`sed '/^\#/d' $PROPS_FILE | grep 'SRC_JPS_CONTEXT_POLICYSTORE'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
destinationJpsContextPolicy=`sed '/^\#/d' $PROPS_FILE | grep 'TGT_JPS_CONTEXT_POLICYSTORE'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
sourceJpsContextCred=`sed '/^\#/d' $PROPS_FILE | grep 'SRC_JPS_CONTEXT_CREDSTORE'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
destinationJpsContextCred=`sed '/^\#/d' $PROPS_FILE | grep 'TGT_JPS_CONTEXT_CREDSTORE'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
backupPolicyStoreFile=`sed '/^\#/d' $PROPS_FILE | grep 'POLICYSTORE_FILE_NAME'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
backupCredStoreFile=`sed '/^\#/d' $PROPS_FILE | grep 'CREDSTORE_FILE_NAME'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
wccVaultLoc=`sed '/^\#/d' $PROPS_FILE | grep 'WCC_VAULT_LOC'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
wccWeblayoutLoc=`sed '/^\#/d' $PROPS_FILE | grep 'WCC_WEBLAYOUT_LOC'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`

#Data dump files that database schema data is exported to or imported from
wcdmp=wcdmp.dmp
mdsdmp=mdsdmp.dmp
discussionsdmp=discussionsdmp.dmp
ocsdmp=ocsdmp.dmp
activitiesdmp=activities.dmp
portletdmp=portlet.dmp

#Portlet client metadata export archive (.EAR) that portlet client metadata is exported to or imported from
portletdatafilename=portletdata.ear

#Audit configuration file that audit information is exported to or imported from
auditFileName=audit.xml

#Running WebCenter Portal back up and recovery scripts...

#On backup - Create a folder with a timestamp under the dump_directory folder
#On restore - Read user specified base directory to import from
current_time=$(date "+%Y.%m.%d-%H.%M.%S")
backup_directory=$dump_directory
if [ ! -z "$exportimport" ]; then
  if [ $exportimport = 'export' ]; then
    #'Creating backup directory.'
    backup_directory=$dump_directory/$current_time
    rm -rf $backup_directory
    mkdir $backup_directory
  fi
  if [ $exportimport = 'import' ]; then
    backup_directory=$dump_directory
  fi
fi

#Writing output to a log file
outputLogFile=$2
# Create a pipe file
mknod $backup_directory/pipefile.$$ p
# Start tee process in background to read it and output content to screen and log file
rm -rf $backup_directory/$outputLogFile
tee $backup_directory/$outputLogFile <$backup_directory/pipefile.$$ &
exec &>$backup_directory/pipefile.$$


#Common for backup (export) and restore (import)
#Create directories and grant read write permissions
export ORACLE_HOME=$oracle_db_home
export ORACLE_SID=$oracle_db_sid
export TNS_ADMIN=$ORACLE_HOME/network/admin
cd $oracle_db_home/bin

if [ ! -z "$exportimport" ]; then
  # Start back up (export)
  if [ $exportimport = 'export' ]; then
    echo 'Back up started...'
    if [ -n "$src_webcenter_schema" ] && [ -n "$wcdmp" ]; then
      ./sqlplus "$oracle_db_connect_webcenter as sysdba" << eof_disp
      create or replace directory dmpdir as '$backup_directory';
      GRANT read,write ON directory dmpdir TO public; 
eof_disp
      echo 'Exporting the WEBCENTER  schema...'
      ./expdp \"$oracle_db_connect_webcenter as sysdba\" directory=dmpdir
 dumpfile=$wcdmp  SCHEMAS=$src_webcenter_schema EXCLUDE=STATISTICS NOLOGFILE=y
    fi
    if [ -n "$src_mds_schema" ] && [ -n "$mdsdmp" ]; then
      ./sqlplus "$oracle_db_connect_mds as sysdba" << eof_disp
      create or replace directory dmpdir as '$backup_directory';
      GRANT read,write ON directory dmpdir TO public; 
eof_disp
      echo 'Exporting the MDS schema...'
      ./expdp \"$oracle_db_connect_mds as sysdba\" directory=dmpdir
 dumpfile=$mdsdmp  SCHEMAS=$src_mds_schema EXCLUDE=STATISTICS NOLOGFILE=y
    fi
    if [ -n "$src_discussions_schema" ] && [ -n "$discussionsdmp" ]; then
      ./sqlplus "$oracle_db_connect_discussions as sysdba" << eof_disp
      create or replace directory dmpdir as '$backup_directory';
      GRANT read,write ON directory dmpdir TO public; 
eof_disp
      echo 'Exporting the DISCUSSIONS schema...'
      ./expdp \"$oracle_db_connect_discussions as sysdba\" directory=dmpdir
 dumpfile=$discussionsdmp  SCHEMAS=$src_discussions_schema EXCLUDE=STATISTICS
 NOLOGFILE=y
    fi
    if [ -n "$src_ocs_schema" ] && [ -n "$ocsdmp" ]; then
      ./sqlplus "$oracle_db_connect_ocs as sysdba" << eof_disp
      create or replace directory dmpdir as '$backup_directory';
      GRANT read,write ON directory dmpdir TO public; 
eof_disp
      echo 'Exporting the OCS schema...'
      ./expdp \"$oracle_db_connect_ocs as sysdba\" directory=dmpdir
 dumpfile=$ocsdmp  SCHEMAS=$src_ocs_schema EXCLUDE=STATISTICS NOLOGFILE=y
      if [ -n "$wccVaultLoc" ]; then
        echo -e '\nExporting vault files for WebCenter Content...'
        cd $backup_directory
        tar cvf wcc_vault.tar -C $wccVaultLoc/vault .
        if [ -f "$backup_directory/wcc_vault.tar" ]; then
          echo -e '\nExported vault files for WebCenter Content to:
 '$backup_directory'/wcc_vault.tar'
        fi
        cd $oracle_db_home/bin
      fi 
      if [ -n "$wccWeblayoutLoc" ]; then
        echo -e '\nExporting weblayout files for WebCenter Content...'
        cd $backup_directory
        tar cvf wcc_weblayout.tar -C $wccWeblayoutLoc/weblayout .
        if [ -f "$backup_directory/wcc_weblayout.tar" ]; then
          echo -e '\nExported weblayout files for WebCenter Content to:
 '$backup_directory'/wcc_weblayout.tar'
        fi
        cd $oracle_db_home/bin
      fi
    fi
    if [ -n "$src_activities_schema" ] && [ -n "$activitiesdmp" ]; then
      ./sqlplus "$oracle_db_connect_ocs as sysdba" << eof_disp
      create or replace directory dmpdir as '$backup_directory';
      GRANT read,write ON directory dmpdir TO public; 
eof_disp
      echo 'Exporting the ACTIVITIES schema...'
      ./expdp \"$oracle_db_connect_activities as sysdba\" directory=dmpdir
 dumpfile=$activitiesdmp  SCHEMAS=$src_activities_schema EXCLUDE=STATISTICS
 NOLOGFILE=y
    fi
    if [ -n "$src_portlet_schema" ] && [ -n "$portletdmp" ]; then
      ./sqlplus "$oracle_db_connect_ocs as sysdba" << eof_disp
      create or replace directory dmpdir as '$backup_directory';
      GRANT read,write ON directory dmpdir TO public; 
eof_disp
      echo 'Exporting the PORTLET schema...'
      ./expdp \"$oracle_db_connect_portlet as sysdba\" directory=dmpdir
 dumpfile=$portletdmp  SCHEMAS=$src_portlet_schema EXCLUDE=STATISTICS NOLOGFILE=y
    fi

    #Call the WLST command script.
    cd $wlstlocation 
    ./wlst.sh $wlstscriptfile $exportimport $username $password $adminconsole
 $backup_directory/$portletdatafilename $wcpServer $jpsConfigFile
 $sourceJpsContextPolicy $destinationJpsContextPolicy $sourceJpsContextCred
 $destinationJpsContextCred $backup_directory/$auditFileName

#Copy the backup policy store and credential store files to the backup location.
    if [ -f "$backupPolicyStoreFile" ]; then
      mv $backupPolicyStoreFile $backup_directory
    fi
    if [ -f "$backupCredStoreFile" ]; then
      mv $backupCredStoreFile $backup_directory
    fi
    echo 'Back up completed successfully. Backup created at location:
 '$backup_directory'. Check the log file: '$backup_directory/$outputLogFile' for additional details.'
  fi

  #Start restore (import)...  
  if [ $exportimport = 'import' ]; then
    echo 'Restore started...'
    if [ -f "$backup_directory/wcc_vault.tar" ]; then
        echo -e '\nImporting vault files for WebCenter Content...'
        cd $wccVaultLoc/vault
        tar xvf $backup_directory/wcc_vault.tar
        echo -e '\nImported vault files for WebCenter Content from:
 '$backup_directory'/wcc_vault.tar to the location: '$wccVaultLoc'/vault'
    fi
      if [ -f "$backup_directory/wcc_weblayout.tar" ]; then
        echo -e '\nImporting weblayout files for WebCenter Content...'
        cd $wccWeblayoutLoc/weblayout
        tar xvf $backup_directory/wcc_weblayout.tar
        echo -e '\nImported weblayout files for WebCenter Content from:
 '$backup_directory'/wcc_weblayout.tar to the location:
 '$wccWeblayoutLoc'/weblayout'
      fi
    #Call the WLST commands script. 
    cd $wlstlocation
    ./wlst.sh $wlstscriptfile $exportimport $username $password $adminconsole
 $backup_directory/$portletdatafilename $wcpServer $jpsConfigFile
 $destinationJpsContextPolicy $sourceJpsContextPolicy $destinationJpsContextCred
 $sourceJpsContextCred $backup_directory/$auditFileName
    echo 'Restoration completed successfully. Check the log file:
 '$backup_directory/$outputLogFile' for additional details.'
  fi
fi
#Clean up pipe file
rm -f $backup_directory/pipefile.$$

41.8.1.2 wlst_script.py

wlst_script.sh is shown in Example 41-13.

This script connects to the Admin Console for your WebCenter Portal installation, and then either backs up (exports) or restores (imports) the following:

  • Portlet client metadata

  • Policy store

  • Credential store

  • Audit configuration information

Export WLST Commands Executed During Back Up

During back up, the script executes the following WLST export commands:

  • exportPortletClientMetadata(appName, fileName, server)

  • migrateSecurityStore(type='appPolicies', configFile, src, dst, overWrite, srcApp, dstApp)

  • migrateSecurityStore(type='credStore', configFile, src, dst)

  • exportAuditConfig(fileName)

Import WLST Commands Executed During Restore

During restore, the script executes the following WLST import commands:

  • importPortletClientMetadata(appName, fileName, server)

  • migrateSecurityStore(type='appPolicies', configFile, src, dst, overWrite, srcApp, dstApp)

  • migrateSecurityStore(type='credStore', configFile, src, dst)

  • importAuditConfig(fileName)

See Also:

If you want to back up or restore individual items, refer to the appropriate section in Section 41.6, "Backing Up an Entire WebCenter Portal Installation" or Section 41.7, "Restoring an Entire WebCenter Portal Installation."

Example 41-13 Sample Script - wlst_script.py

## wlst_script.py
## Python script that runs export and import WLST commands.
############ No User Input Required ###################

# Get user credentials and other parameters from the properties file
exportOrImport = sys.argv[1]
username = sys.argv[2]
password = sys.argv[3]
adminconsole = sys.argv[4]
fileName = sys.argv[5]
wcpServerName = sys.argv[6]
jpsConfigFile = sys.argv[7]
destination = sys.argv[8]
source = sys.argv[9]
dstCred = sys.argv[10]
sourceCred = sys.argv[11]
auditFileName=sys.argv[12]
 
# Connect to the given host
connect(username,password,adminconsole)
 
if (exportOrImport == 'export' ):
# Run export WLST commands
  # Export portlet data
  print 'Exporting portlet data...'
  exportPortletClientMetadata(appName='webcenter', fileName=fileName, server=wcpServerName)
  if webcenterErrorOccurred(): # COMMAND STATUS
      print "Error while exporting the portlet data."
  else:
      print 'Successfully exported the portlet data.'
 
  # Export security
  print 'Exporting the policy store...'
  migrateSecurityStore(type='appPolicies', configFile=jpsConfigFile, src=source,
 dst=destination, overWrite='true', srcApp='webcenter', dstApp='webcenter')
  print 'Exporting the credential store...'
  migrateSecurityStore(type='credStore', configFile=jpsConfigFile, src=sourceCred,
 dst=dstCred)
  print 'Exporting audit configuration...'
  exportAuditConfig(fileName=auditFileName)
 
elif (exportOrImport == 'import' ):
# Run import WLST commands
  # Import portlet data
  print 'Importing portlet data...'
  importPortletClientMetadata(appName='webcenter', fileName=fileName, server=wcpServerName)
  if webcenterErrorOccurred(): # COMMAND STATUS
      print "Error while importing portlet data."
  else:
      print 'Successfully imported portlet data.'
 
  # Import security
  print 'Importing the policy store...'
  migrateSecurityStore(type='appPolicies', configFile=jpsConfigFile, src=source, dst=destination, overWrite='true', srcApp='webcenter', dstApp='webcenter')
  print 'Importing the credential store...'
  migrateSecurityStore(type='credStore', configFile=jpsConfigFile, src=sourceCred, dst=dstCred)
  print 'Importing audit configuration...'
  importAuditConfig(fileName=auditFileName)

41.8.1.3 backup.properties and restore.properties Files

The backup.properties file contains input parameters for backup commands in master_script.sh and wlst_script.py. For example, file names, database home location, database connect string, schema names, and so on.

A similar .properties file (restore.properties) is required to define input parameters for restore commands.

Table 41-5 lists and describes the input parameters in backup.properties and restore.properties files.

Example 41-14 shows a backup.properties file with sample values.

Example 41-15 shows a restore.properties file with sample values.

Table 41-5 User Defined Parameters for Backup and Restore Scripts

Backup / Restore Parameter Description Example

OPERATION

Determines whether the script backs up WebCenter Portal data (exports) or restores WebCenter Portal data (imports).

For backup:

export

For restore:

import

Database information

    

DATA_DIRECTORY

For backup scripts:

Location on the file system under which backup files created by the script are stored.

Each time you run the script, a new subdirectory is created under the directory specified here. The name of each subdirectory includes a timestamp, such as 2013.03.18-05.20.28.

For restore scripts:

Directory containing the back up you want to restore from.

For backup:

DATA_DIRECTORY=/scratch/aime1/mywebcenterportal_backupscripts/mybackups

For restore:

DATA_DIRECTORY=/scratch/aime1/mywebcenterportal_backupscripts/mybackups/2013.03.18-05.20.28

DB_ORACLE_HOME

Database home directory.

/scratch/aime1/mywork/db1234

DB_ADMIN_USER

Database admin user.

mydbadminuser

DB_ADMIN_PASSWORD

Password for the database admin user.

mypassword

DB_SID

Database SID.

db1234

WebCenter Content folders

  

For backup and restore:

WCC_VAULT_LOC

Location on the file system for WebCenter Content vault files.

/scratch/aime1/mwork/mymw/user_projects/domains/WLS_WC/ucm/cs

WCC_WEBLAYOUT_LOC

Location of the file system for WebCenter Content weblayout files.

/scratch/aime1/mwork/mymw/user_projects/domains/WLS_WC/ucm/cs

Database connect strings
(Back up scripts only)

Required when OPERATION=export.

For backup only:

DB_CONNECT_WEBCENTER_SCHEMA

Connect string for the WEBCENTER database schema you want to export.

mydbadmin/mypassword@db1234

DB_CONNECT_MDS_SCHEMA

Connect string for the MDS database schema you want to export.

mydbadmin/mypassword@db1234

DB_CONNECT_OCS_SCHEMA

Connect string for the OCS database schema you want to export.

mydbadmin/mypassword@db1234

DB_CONNECT_DISCUSSIONS_SCHEMA

Connect string for the DISCUSSIONS database schema you want to export.

mydbadmin/mypassword@db1234

DB_CONNECT_ACTIVITIES_SCHEMA

Connect string for the ACTIVITIES database schema you want to export.

mydbadmin/mypassword@db1234

DB_CONNECT_PORTLET_SCHEMA

Connect string for the PORTLET database schema you want to export.

mydbadmin/mypassword@db1234

Database schemas to export
(Back up scripts only)

Required when OPERATION=export.

For backup only:

EXP_WEBCENTER_SCHEMA

Name of the WEBCENTER schema to export.

mysrcprefix_WEBCENTER

EXP_MDS_SCHEMA

Name of the MDS schema to export.

mysrcprefix_MDS

EXP_DISCUSSIONS_SCHEMA

Name of the DISCUSSIONS schema to export.

mysrcprefix_DISCUSSIONS

EXP_DISCUSSIONS_CRAWLER_SCHEMA

Name of the DISCSUSSIONS_CRAWLER schema to export.

mysrcprefix_DISCUSSIONS_CRAWLER

EXP_OCS_SCHEMA

Name of the OCS schema to export.

mysrcprefix_OCS

EXP_ACTIVITIES_SCHEMA

Name of the ACTIVITIES schema to export.

mysrcprefix_ACTIVITIES

EXP_PORTLET_SCHEMA

Name of the PORTLET schema to export.

mysrcprefix_PORTLET

WLST Export and Import

  

For backup and restore:

WLST - General

    

WLST_ADMIN_USER

Name of the administrative user connecting WLST to the Administration Server.

mywlstadmin

WLST_ADMIN_PASSWORD

Password of the administrative user.

  

WLST_ADMIN_CONSOLE

Host name and port of the Administration Server, specified using the format:

 protocol://listen_address:listen_port

t3://myhost.com:24647

WLST_LOCATION

Location of the WLST script. You must run all Oracle WebCenter Portal WLST commands from your WebCenter Portal Oracle home directory (WCP_ORACLE_HOME):

WCP_ORACLE_HOME/common/bin/wlst.sh

/scratch/aime1/mywork/mymw/mywcp_oraclehome/common/bin

WLST_SCRIPT_LOCATION

Location of the WLST backup and restore script.

/scratch/aime1/myportal_server_scripts/wlst_script.py

WCP_SERVER_NAME

Name of the managed server on which the WebCenter Portal application (webcenter) is deployed.

WC_Spaces

WLST - Security

    

JPS_CONFIG_FILE

Name and location of the configuration file (by default, named jps-config.xml) relative to the directory where the WLST command is run.

/scratch/aime1/mywork/mymw/user_projects/domains/myDomainHome/config/fmwconfig/backup-config-mycopy.xml

SRC_JPS_CONTEXT_POLICYSTORE

Name of a jps-context in the configuration file, where the source policy store is specified.

mysourcePolicy

TGT_JPS_CONTEXT_POLICYSTORE

Name of another jps-context in the configuration file, where the target policy store is specified.

mytargetPolicy

SRC_JPS_CONTEXT_CREDSTORE

Name of a jps-context in the configuration file, where the source credential store is specified.

mysourceCred

TGT_JPS_CONTEXT_CREDSTORE

Name of another jps-context in the configuration file, where the target credential store is specified.

mytargetCred

POLICYSTORE_FILE_NAME

Name and location of the policy store that you want to back up or restore (as specified in JPS_CONFIG_FILE)

/scratch/portal_server_scripts/backup/backup-system-jazn-data.xml

CREDSTORE_FILE_NAME

Name and location of the credential store that you want to back up ore restore (location is as specified in JPS_CONFIG_FILE, with the file name cwallet.sso)

/scratch/portal_server_scripts/backup/cwallet.sso

Example 41-14 Sample Backup Script Properties - backup.properties

## backup.properties for backing up WebCenter Portal
## Specify valid values for your environment
############ User Input Required #############

##OPERATION - Specify either export or import
##  For backup scripts, specify OPERATION=export
##  For restore scripts, specify OPERATION=import
##
OPERATION=export

##Specify database information
##For backup scripts, specify source database details here
## 
##   DATA_DIRECTORY    Location on the file system that contains the backup
##                     scripts files
##   DB_ORACLE_HOME    Database home directory
##   DB_ADMIN_USER     Database admin user
##   DB_ADMIN_PASSWORD Password for the database admin user
##   DB_SID            Database SID
##
DATA_DIRECTORY=/scratch/aime1/mywebcenterportal_scripts/mybackups
DB_ORACLE_HOME=/scratch/aime1/mywork/db1234
DB_ADMIN_USER=mydbadmin
DB_ADMIN_PASSWORD=mypassword
DB_SID=db1234

##Specify WebCenter Content vault and weblayout file location information
##For backup scripts, specify the source directories here
##
WCC_VAULT_LOC=/scratch/aime1/mywork/mymw/user_projects/domains/myDomainHome/ucm/cs
WCC_WEBLAYOUT_LOC=/scratch/aime1/mwork/mymw/user_projects/domains/myDomainHome/ucm/cs
 
##Specify a connect string for each schema to export
##For backup scripts, specify connect strings for the source schemas here
## Use the format: <adminuser>/<password>@<serviceID>
## For example: mydbadmin/mypassword@db1234
##
DB_CONNECT_WEBCENTER_SCHEMA=mydbadmin/mypassword@db1234
DB_CONNECT_MDS_SCHEMA=mydbadmin/mypassword@db1234
DB_CONNECT_OCS_SCHEMA=mydbadmin/mypassword@db1234
DB_CONNECT_DISCUSSIONS_SCHEMA=mydbadmin/mypassword@db1234
DB_CONNECT_ACTIVITIES_SCHEMA=mydbadmin/mypassword@db1234
DB_CONNECT_PORTLET_SCHEMA=mydbadmin/mypassword@db1234
 
##Database schemas to export

##Identify source database schemas to export
##For back up scripts, specify source schema names here.
##
EXP_WEBCENTER_SCHEMA=myprefix_WEBCENTER
EXP_MDS_SCHEMA=myprefix_MDS
EXP_DISCUSSIONS_SCHEMA=myprefix_DISCUSSIONS
EXP_DISCUSSIONS_CRAWLER_SCHEMA=myprefix_DISCUSSIONS_CRAWLER
EXP_OCS_SCHEMA=myprefix_OCS
EXP_ACTIVITIES_SCHEMA=myprefix _ACTIVITIES
EXP_PORTLET_SCHEMA=myprefix_PORTLET

 
##Specify information for WLST export commands

##Specify general WLST information
##For backup scripts, specify details for the source system here
## 
## WLST_ADMIN_USER     Name of the admin user connecting WLST to the Admin Server
## WLST_ADMIN_PASSWORD Password of the admin user
## WLST_ADMIN_CONSOLE  Host name and port of the Admin Server. Use the format:
##                     protocol://listen_address:listen_port
## WLST_LOCATION   Location of the WLST script. You must run WebCenter Portal WLST
##                 commands from your WebCenter Portal Oracle home directory
##                 (WCP_ORACLE_HOME/common/bin/wlst.sh)
## WLST_SCRIPT_LOCATION Location of the back up script (wlst_script.py)
## WCP_SERVER_NAME Name of the managed server on which the WebCenter Portal
##                 application (webcenter) is deployed
## 
WLST_ADMIN_USER=mywlstadmin
WLST_ADMIN_PASSWORD=mypassword
WLST_ADMIN_CONSOLE=t3://myhost.com:24647
WLST_LOCATION=/scratch/aime1/mywork/mymw/mywcp/common/bin
WLST_SCRIPT_LOCATION=/scratch/aime1/mywebcenterportal_scripts/wlst_script.py
WCP_SERVER_NAME=WC_Spaces

## Specify information for security export
## (Policy store and credential store)
## Provide details about the security configuration file (jps-config.xml).
## For backup scripts, specify details about the source jps-config.xml here
##
## JPS_CONFIG_FILE              Location of the configuration file relative to
##                              the directory from which WLST commands run
## SRC_JPS_CONTEXT_POLICYSTORE  Name of a jps-context in the configuration file,
##                              where the source policy store is specified
## TGT_JPS_CONTEXT_POLICYSTORE  Name of another jps-context in the configuration
##                              file, where the target policy store is specified
## SRC_JPS_CONTEXT_CREDSTORE    Name of a jps-context in the configuration file,
##                              where the source credential store is specified
## TGT_JPS_CONTEXT_CREDSTORE  Name of another jps-context in the configuration
##                            file, where the target credential store is specified
## POLICYSTORE_FILE_NAME      Name and location of the policy store that you
##                            wamt to back up (as specified in JPS_CONFIG_FILE)
## CREDSTORE_FILE_NAME        Name and location of the credential store that you
##                            want to back up (location is as specified in
##                            JPS_CONFIG_FILE, with the file name cwallet.sso)
## 
JPS_CONFIG_FILE=/scratch/aime1/mywork/mymw/user_projects/domains/MyDomainHome/config/fmwconfig/mybackup-jps-config.xml
SRC_JPS_CONTEXT_POLICYSTORE=mysourcePolicy
TGT_JPS_CONTEXT_POLICYSTORE=mytargetPolicy
SRC_JPS_CONTEXT_CREDSTORE=mysourceCred
TGT_JPS_CONTEXT_CREDSTORE=mytargetCred
POLICYSTORE_FILE_NAME=/scratch/aime1/mywebcenterportal_scripts/backup/backup-system-jazn-data.xml
CREDSTORE_FILE_NAME=/scratch/aime1/mywebcenterportal_scripts/backup/cwallet.sso

Example 41-15 Sample Restore Script Properties - restore.properties

## restore.properties for restoring WebCenter Portal from a backup
## Specify valid values for your environment
############ User Input Required #############

##OPERATION - Specify either export or import
##  For backup scripts, specify OPERATION=export
##  For restore scripts, specify OPERATION=import
##
OPERATION=import

##Specify database information
##  For restore scripts, specify target database details here
## 
##   DATA_DIRECTORY    Location on the file system that contains the backup
##                     files you want to restore
##   DB_ORACLE_HOME    Database home directory
##   DB_ADMIN_USER     Database admin user
##   DB_ADMIN_PASSWORD Password for the database admin user
##   DB_SID            Database SID
##
DATA_DIRECTORY=/scratch/aime1/mywebcenterportal_scripts/mybackups/2013.05.30-08.39.28
DB_ORACLE_HOME=/scratch/aime1/mywork/db1234
DB_ADMIN_USER=mydbadmin
DB_ADMIN_PASSWORD=mypassword
DB_SID=db1234

##Specify WebCenter Content vault and weblayout file location information
##  For restore scripts, specify the target directories here
##
WCC_VAULT_LOC=/scratch/aime1/mywork/mymw/user_projects/domains/myDomainHome/ucm/cs
WCC_WEBLAYOUT_LOC=/scratch/aime1/mwork/mymw/user_projects/domains/myDomainHome/ucm/cs

##Specify information for WLST import commands

##Specify general WLST information
## For restore scripts, specify details for the target system here
## 
## WLST_ADMIN_USER     Name of the admin user connecting WLST to the Admin Server
## WLST_ADMIN_PASSWORD Password of the admin user
## WLST_ADMIN_CONSOLE  Host name and port of the Admin Server. Use the format:
##                     protocol://listen_address:listen_port
## WLST_LOCATION   Location of the WLST script. You must run WebCenter Portal WLST
##                 commands from your WebCenter Portal Oracle home directory
##                 (WCP_ORACLE_HOME/common/bin/wlst.sh)
## WLST_SCRIPT_LOCATION Location of the restore script (wlst_script.py)
## WCP_SERVER_NAME Name of the managed server on which the WebCenter Portal
##                 application (webcenter) is deployed
## 
WLST_ADMIN_USER=mywlstadmin
WLST_ADMIN_PASSWORD=mypassword
WLST_ADMIN_CONSOLE=t3://myhost.com:24647
WLST_LOCATION=/scratch/aime1/mywork/mymw/mywcp/common/bin
WLST_SCRIPT_LOCATION=/scratch/aime1/mywebcenterportal_scripts/wlst_script.py
WCP_SERVER_NAME=WC_Spaces

## Specify information for security import
## (Policy store and credential store)
## Provide details about the security configuration file (jps-config.xml).
## For restore scripts, specify details about the target jps-config.xml here
##
## JPS_CONFIG_FILE              Location of the configuration file relative to
##                              the directory from which WLST commands run
## SRC_JPS_CONTEXT_POLICYSTORE  Name of a jps-context in the configuration file,
##                              where the source policy store is specified
## TGT_JPS_CONTEXT_POLICYSTORE  Name of another jps-context in the configuration
##                              file, where the target policy store is specified
## SRC_JPS_CONTEXT_CREDSTORE    Name of a jps-context in the configuration file,
##                              where the source credential store is specified
## TGT_JPS_CONTEXT_CREDSTORE  Name of another jps-context in the configuration
##                            file, where the target credential store is specified
## POLICYSTORE_FILE_NAME      Name and location of the policy store that you
##                            wamt to restore (as specified in JPS_CONFIG_FILE)
## CREDSTORE_FILE_NAME        Name and location of the credential store that you
##                            want to restore (location is as specified in
##                            JPS_CONFIG_FILE, with the file name cwallet.sso)
## 
JPS_CONFIG_FILE=/scratch/aime1/mywork/mymw/user_projects/domains/MyDomainHome/config/fmwconfig/restore-jps-config.xml
SRC_JPS_CONTEXT_POLICYSTORE=mysourcePolicy
TGT_JPS_CONTEXT_POLICYSTORE=mytargetPolicy
SRC_JPS_CONTEXT_CREDSTORE=mysourceCred
TGT_JPS_CONTEXT_CREDSTORE=mytargetCred
POLICYSTORE_FILE_NAME=/scratch/aime1/mywebcenterportal_scripts/mybackups/2013.05.30-08.39.2/backup-system-jazn-data.xml
CREDSTORE_FILE_NAME=/scratch/aime1/mywebcenterportal_scripts/mybackups/2013.05.30-08.39.28/cwallet.sso

41.8.2 Using Scripts to Back Up WebCenter Portal

This section describes how to set up, verify, and schedule WebCenter Portal backups using scripts files:

  1. Create backup scripts (first time only).

  2. Complete prerequisite tasks for security store back up (first time only).

  3. Set backup parameters and customize scripts (first time only).

  4. Run the backup script.

  5. Verify backup archives.

  6. Schedule regular back ups using the scripts.

Create backup scripts

(First time only)

  1. Create a directory on the file system for your scripts and backups.

    For example: /scratch/aime1/mywebcenterportal_scripts/backups

  2. Copy code from Example 41-12, "Sample Script - master_script.sh", paste into a text editor, and save the file as master_script_backup.sh into the directory you created in step 1.

    Note:

    Ensure that the script does not contain any hidden characters or DOS characters if running on Unix/Linux.

  3. Copy code from Example 41-13, "Sample Script - wlst_script.py", paste into a text editor, and save the file as wlst_script.py in the same directory.

  4. Copy code from Example 41-14, "Sample Backup Script Properties - backup.properties", paste into a text editor, and save the file as backup.properties in the same directory.

Complete prerequisite tasks for security store back up

(First time only)

In the source environment:

  1. Create a copy of your jps-config.xml file for the backup scripts.

    This file is located at:

    SOURCE_DOMAIN_HOME/config/fmwconfig/jps-config.xml

    Name the copy mybackup-jps-config.xml or similar and save it at the same location. For example, /scratch/aime1/mywork/mymw/user_projects/domains/MyDomainHome/config/fmwconfig/mybackup-jps-config.xml

  2. Configure source and target information for backing up the policy store as follows:

    1. To point to the target policy store, add the following section (above the closing </serviceInstances> tag):

      <serviceInstance 
        name="policystore.backup.xml"
        provider="policystore.xml.provider"
        location="<some_location>/mybackup-system-jazn-data.xml">
   <description>File Based Policy Store Service Instance</description>
 </serviceInstance>

      You can choose any location that the backup scripts can access. For example:

      /scratch/aime1/mywebcenterportal_scripts/backups/backup-system-jazn-data.xml

      Where, backup-system-jazn-data.xml is a copy of system-jazn-data.xml located at:

      /scratch/aime1/mywork/mymw/user_projects/domains/MyDomainHome/config/fmwconfig/

    2. Add and configure the following entries (above the closing </jpsContexts> tag):

      <jpsContext name="mysourcePolicy">
     <serviceInstanceRef ref="policystore.ldap"/>
</jpsContext>

<jpsContext name="mytargetPolicy"> 
     <serviceInstanceRef ref="policystore.backup.xml"/>
</jpsContext>

  3. Configure source and target information for backing up the credential store as follows:

    1. To point to the target credential store, add the following section (above the closing </serviceInstances> tag):

      <serviceInstance 
        name="credstore.backup.xml"
        provider="credstore.xml.provider"
        location="<some_location>">
   <description>File Based Credential Store Service Instance</description>
 </serviceInstance>

      You can choose any location that the backup scripts can access. For example, /scratch/aime1/mywebcenterportal_scripts/backups.

    2. Add and configure the following entries (above the closing </jpsContexts> tag):

      <jpsContext name="mysourceCred">
     <serviceInstanceRef ref="credstore.ldap"/>
</jpsContext>

<jpsContext name="mytargetCred"> 
     <serviceInstanceRef ref="credstore.backup.xml"/>
</jpsContext>

Set backup parameters and customize scripts

(First time only)

  1. Open backup.properties in a text editor.

  2. Ensure OPERATION=export.

  3. Specify values for parameters in the file.

    Refer to Table 41-5 for a description of each parameter.

    Note:

    You can comment out parameters that are not required.

  4. Customize the backup scripts, if required.

    To exclude objects, comment out the associated backup command code. To back up additional objects using the script, add the required code.

  5. Save the changes.

Run the backup script

  1. Set the following environment variables:

    ORACLE_HOME

    ORACLE_SID

    TNS_ADMIN

  2. Verify that you have permissions to read and write to all directories used during the backup process.

  3. Run the master backup script, specifying the name of the backup properties file and a log file name as follow:

    sh master_backup_script_name backup_properties_file_name log_file_name

    For example:

    sh master_script_backup.sh backup.properties mybackup.log

    The message "Backup completed successfully..." indicates when the backup process is complete and the directory in which your backups and the export.log file are located.

    Each time you run the script, backup data is saved to a different folder under the main backup folder (DATA_DIRECTORY) so that previous backups are retained. Timestamp information is included in backup folder names so its easy to associate your backups with a particular date and time.

Verify backup archives

  1. Navigate to the directory containing your data backups, that is, a timestamped folder under the location you specified for the DATA_DIRECTORY parameter in backup.properties.

  2. Verify the following backup files are available:

    • one or more .dmp files

    • wcc_vault.tar

    • wcc_weblayout.tar

    • portletdata.ear

    • backup-system-jazn-data.xml

    • cwallet.sso

    • audit.xml

    • .log file

Schedule regular back ups using the scripts

Once you have verified your backup script configuration by successfully creating data backups with master_script_backup.sh, Oracle recommends that you schedule back ups at regular intervals.

Each time you run the script, backup data is saved to a different folder under the main backup folder (DATA_DIRECTORY) so that previous backups are retained.

To minimize data-integrity issue during data back up, Oracle recommends that you do not schedule backups during peak usage time.

41.8.3 Restoring WebCenter Portal from Backups Using Scripts

This section describes how to restore a WebCenter Portal installation from backups using scripts files:

  1. Create restore scripts (first time only).

  2. Complete prerequisite tasks for security store restore (first time only).

  3. Set restore script parameters (first time only).

  4. Restore database schemas manually.

  5. Run the restoration script.

  6. Verify restored data.

Create restore scripts

(First time only)

  1. Duplicate the backup scripts that you created earlier master_script.sh wlst_script.py (following steps in section Using Scripts to Back Up WebCenter Portal) and copy them to a different location.

    For example: /scratch/aime1/mywebcenterportal_scripts/restore

  2. Copy code from Example 41-15, "Sample Restore Script Properties - restore.properties", paste into a text editor, and save the file as restore.properties in the same directory.

  3. Rename the files, if required.

    For example: master_script_restore.sh, wlst_restore_script.py, restore.properties

Restore database schemas manually

  1. Ensure that all the target schemas were created using RCU and the names of the target schemas match the source schema names.

  2. (Optional). If you want to point the default data sources to different schemas, use the WebLogic Server Admin Console to update the schema names, and database details.

  3. Stop all the servers.

  4. Restore schema data, as required.

    Important:

    Database schemas WEBCENTER and MDS must be restored together to ensure the data is in-sync.

    If you need to restore additional schemas, such as PORTLET or OCS, you must restore them at the same time, after WEBCENTER and MDS, and from the same point to maintain data integrity.

    This example shows you commands to restore WEBCENTER and MDS schemas:

    ./sqlplus "sys/password@serviceid as sysdba"
create or replace directory dmpdir as 'mydmpdirectory';
GRANT read,write ON directory dmpdir TO public;

##Drop WEBCENTER and MDS schemas ##

drop user srcprefix_WEBCENTER cascade;
drop user srcpreix_MDS cascade;
exit;
./impdp \"sys/password@serviceid as sysdba\" directory=dmpdir dumpfile=webcenterportal.dmp SCHEMAS=srcprefix_WEBCENTER
./impdp \"sys/password@serviceid as sysdba\" directory=dmpdir dumpfile=mds.dmp SCHEMAS=srcprefix_MDS

    Where:

    • password is the password for the system database user.

    • serviceid is the unique SID for the database. For example, mydb1234.

    • directory is the location on the database machine where the dump files are located.

    • dumpfile is the name of the file that contains data to be imported.

    • SCHEMAS identifies the target schemas. Schema names include the RCU suffix that was used during installation (_WEBCENTER and _MDS), along with a user supplied prefix. For example, DEV_WEBCENTER.

      Schema names on the source and target must match. For example, both schemas must be named DEV_WEBCENTER.

    For example:

    ./sqlplus "sys/mypassword@db1234 as sysdba"
create or replace directory dmpdir as '/scratch/mywebcenterportal_scripts/backup/2013.05.04-02.36.48';
GRANT read,write ON directory dmpdir TO public;

##Drop WEBCENTER and MDS schemas ##

drop user DEV_WEBCENTER cascade;
drop user DEV_MDS cascade;
exit;
./impdp \"sys/mypassword@db1234 as sysdba\" directory=dmpdir dumpfile=wcdmp.dmp SCHEMAS=DEV_WEBCENTER
./impdp \"sys/mypassword@db1234 as sysdba\" directory=dmpdir dumpfile=mdsdmp.dmp SCHEMAS=DEV_MDS

    Note:

    If you need to restore other schemas, such as DISCUSSIONS, PORTLETS, ACTIVITIES, and OCS, then do so now before starting the servers.

  5. Start all the servers.

Complete prerequisite tasks for security store restore

(First time only)

In the target environment:

  1. Create a copy of your jps-config.xml file for the restore scripts.

    This file is located at:

    TARGET_DOMAIN_HOME/config/fmwconfig/jps-config.xml

    Name the copy myrestore-jps-config.xml or similar and save it at the same location. For example, /scratch/aime1/mywork/mymw/user_projects/domains/MyDomainHome/config/fmwconfig/myrestore-jps-config.xml

  2. Configure source and target information for restoring the policy store as follows:

    1. To point to the source policy store, add the following section (above the closing </serviceInstances> tag):

      <serviceInstance 
        name="policystore.backup.xml"
        provider="policystore.xml.provider"
        location="<some_location>/mybackup-system-jazn-data.xml">
   <description>File Based Policy Store Service Instance</description>
 </serviceInstance>

      The location you specify must contain a previously backed up policy store that you want to restore. For example, /scratch/aime1/mywebcenterportal_scripts/backups/2013.06.19-09.20.14/backup-system-jazn-data.xml

    2. Configure the following entries (above the closing </jpsContexts> tag):

      <jpsContext name="targetPolicy">
     <serviceInstanceRef ref="policystore.ldap"/>
</jpsContext>

<jpsContext name="sourcePolicy"> 
     <serviceInstanceRef ref="policystore.backup.xml"/>
</jpsContext>

  3. Configure source and target information for restoring the credential store as follows:

    1. To point to the source credential store, add the following section (above the closing </serviceInstances> tag):

      <serviceInstance 
        name="credstore.backup.xml"
        provider="credstore.xml.provider"
        location="<some_location>">
   <description>File Based Credential Store Service Instance</description>
 </serviceInstance>

      The location you specify must contain a previously backed up credential store (cwallet.sso) that you want to restore. For example, /scratch/aime1/mywebcenterportal_scripts/backups/2013.06.19-09.20.14 .

    2. Configure the following entries (above the closing </jpsContexts> tag):

      <jpsContext name="targetCred">
     <serviceInstanceRef ref="credstore.ldap"/>
</jpsContext>

<jpsContext name="sourceCred"> 
     <serviceInstanceRef ref="credstore.backup.xml"/>
</jpsContext>

Set restore script parameters

(First time only)

  1. Open restore.properties in a text editor.

  2. Ensure that OPERATION=import.

  3. Specify values for all parameters in the file.

    Refer to Table 41-5 for a description of each parameter.

  4. Save the changes.

Run the restoration script

  1. Set the following environment variables:

    ORACLE_HOME

    ORACLE_SID

    TNS_ADMIN

  2. Verify that you have permissions to read and write to all directories used during the restore process.

  3. Run the master restoration script, specifying the name of the restore properties file and a log file name as follow:

    sh master_restore_script_name bestore_properties_file_name log_file_name

    For example:

    sh master_script_restore.sh backup.properties myrestore.log

    The message "Restoration completed successfully..." indicates when the restore process is complete and the directory where the restore.log file is located.

Verify restored data

Check your WebCenter Portal installation:

  1. If you import one or more database schemas, shut down and restart those databases, and restart all managed servers.

  2. Verify the target WebCenter Portal instance includes the restored data.

41.9 Cloning a WebCenter Portal Environment

Cloning creates a new WebCenter Portal environment based on existing ones. You can install, configure, customize, and validate your WebCenter Portal installation and when the system is stable, create another environment by copying all the components and their configurations from the source environment. This saves time as you do not need to redo all the changes you incorporated and tested in the source environment. For more information, see the "Moving Oracle WebCenter Portal to a Target Environment" section in Administrator's Guide.