35 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 Permissions Required to Perform WebCenter Portal Life Cycle Operations.

See also, Understanding Administrative Operations, Roles, and Tools.

35.1 Understanding WebCenter Portal Back Up 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 back up and recovery strategies, see Advanced Administration: Backup and Recovery in Administering Oracle Fusion Middleware.

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

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

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

Category Backup and Restore(Portals and Portal Templates) Backup and Restore Scripts(Full WebCenter Portal Install) Migration / Backup(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 portals 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

Content stored in the portal’s content folder on Content Server, portal pages and assets, and portal data stored in persistence

Portal security permissions and roles.

For details, see:

Understanding Portal Archives

Deploying Portal Templates

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

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 and data stored in the WEBCENTER schema pages, application integration assets, lightweight content items, and tools and services, such as discussions, announcements, events, portlets, activities, and tags.

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, surveys, and tags.

What is not backed up / migrated

Any content outside of the portal’s content folder on Content Server and any shared libraries used by the 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.

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.

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 content outside of the portal’s content folder on Content Server, any shared library used by the portal, and 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 Advanced Administration: Backup and Recovery in Administering Oracle Fusion Middleware.

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 Moving from a Test to a Production Environment in Administering Oracle Fusion Middleware.

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.

35.3 Backing Up Individual Portals

The backup process for portals 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).
  2. Back up discussions and external data for the portal, if required.

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 back up process. For details, see Using Scripts to Back Up and Restore WebCenter Portal.

See also, 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.

35.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 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 back up 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, 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 exportWebCenterPortals in WebCenter WLST Command Reference.

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

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

35.3.2 Backing Up Discussions and External 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 Exporting Portal Discussions to an Archive and Importing Portal Discussions from an Archive.

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.

35.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.
  2. Restore discussions data and external data for the portal, if required.

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 Using Scripts to Back Up and Restore WebCenter Portal.

35.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 Importing New WebCenter Portal Connections from a File.

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

    Portal managers 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 depend on your specific requirements. For command syntax, see importWebCenterPortals in WebCenter WLST Command Reference.

For information on how to run WLST commands, see 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. For information, seeRestoring Discussions and External Data for a Portal.

35.4.2 Restoring Discussions and External Data for a Portal

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

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.

35.5 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 back up 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.
  2. Back up all data in the MDS schema.
  3. Back up all data for Content Server.
  4. Back up all discussions server data.
  5. Back up other schema data stored for WebCenter Portal.
  6. Back up data for portlet producers used by WebCenter Portal.
  7. Back up pagelet producer metadata.
  8. Back up analytics metadata.
  9. Back up security stores.
  10. Back up the WebLogic domain hosting WebCenter Portal.
  11. Back up Audit 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 back up process. For details, see Using Scripts to Back Up and Restore WebCenter Portal.

35.5.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, surveys, and tags.

This section includes the following topics:

35.5.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

35.5.1.2 Back Up (Export) WebCenter Portal Schema Data

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

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

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the command described in the example given below. For detailed expdp command information, see guide.

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, Restore (Import) WebCenter Portal Data.

35.5.1.3 Restore (Import) WebCenter Portal Data

To restore WEBCENTER schema data from a backup, use the appropriate utility for your database. 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.

    For example, to import WebCenter Portal schema data where source and target schema names match, run the following command:

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

    For example, to import WebCenter Portal schema data where source and target schema names are different, run the following command:

    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.

    For detailed impdp command information, see guide.

35.5.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:

35.5.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 back up (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.

35.5.2.2 Back Up (Export) All MDS Schema Data

To back up MDS data, use the appropriate utility for your database. For non-Oracle databases, refer to the manufacturer's documentation.

For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the following command:

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.

For detailed expdp command information, see guide.

See also, Restore (Import) MDS Schema Data.

35.5.2.3 Restore (Import) MDS Schema Data

To restore MDS schema data from a backup, use the appropriate utility for your database. 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. For example, run the following command:
    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.

For detailed impdp command information, see guide.

35.5.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 Advanced Administration: Backup and Recovery in Administering Oracle Fusion Middleware.

Optionally, you can back up the root folder for a WebCenter Portal instance 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 System Migration and Archiving 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.

35.5.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:

35.5.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

35.5.4.2 Back Up (Export) All Discussions Schema Data

To back up all discussions schema data, use the appropriate utility for your database. For non-Oracle databases, refer to the manufacturer's documentation.

For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the following command:

Note:

This section describes how to export all discussions server data. If you want to export discussions for a single portal, see Backing Up Discussions and External Data for a Portal.

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.

For detailed expdp command information, see guide.

See also, Restore (Import) Discussions Schema Data.

35.5.4.3 Restore (Import) Discussions Schema Data

To restore discussions schema data from a backup, use the appropriate utility for your database. 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.

    For example, to import the discussions schema data where source and target schema names match, run the following command:

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

    For example, to import the discussions schema data where source and target schema names are different, run the following command:

    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.

35.5.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 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:

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

  • For an Oracle database, go to DB_ORACLE_HOME/bin of your database and run the commands described in this section.

    For detailed expdp and impdp command information, see guide.

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)

The following example 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.

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)

This section describes 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.

    For example, to import schema data where source and target schema names match, run the following command:

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

    For example, to import schema data where source and target schema names match, run the following command:

    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.

35.5.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 Advanced Administration: Backup and Recovery in Administering Oracle Fusion Middleware.

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

35.5.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. 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 Migrating Policies Manually in Securing Applications with Oracle Platform Security Services.

See also migrateSecurityStore in WebCenter WLST 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 Migrating Entire WebCenter Portal to Another Target.

35.5.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. 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 Migrating All Credentials with migrateSecurityStore in Securing Applications with Oracle Platform Security Services.

See also, migrateSecurityStore in WebCenter WLST Command Reference.

35.5.9 Backing Up and Restoring a WebCenter Portal Domain

For information on how to back up and restore your domain configuration, see Advanced Administration: Backup and Recovery in Administering Oracle Fusion Middleware.

35.5.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. 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 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 o Backing up and Restoring Other Schema Data (ACTIVITIES and PORTLET).

35.5.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, 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 exportPortletClientMetadata in WLST Command Reference for WebLogic Server.

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

35.5.10.2 Restoring (Importing) Portlet Client Metadata

To import portlet client metadata and producer customizations and personalizations, for WebCenter Portal, 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, Backing Up (Exporting) Portlet Client Metadata.

For detailed syntax and examples, see the importPortletClientMetadata and exportPortletClientMetadata in WebCenter WLST Command Reference.

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

35.5.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 Managing Import, Export, Backup and Recovery of Pagelet Producer Components.

35.5.12 Backing Up and Restoring Analytics Metadata

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

35.5.13 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 exportAuditConfig and importAuditConfig in WLST Command Reference for WebLogic Server.

35.6 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:

35.6.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 (.par file) using WLST commands or Fusion Middleware Control, as shown in Figure 35-1.

The WebCenter Portal export archive (.par file) contains several files, as listed in Figure 35-1.

Figure 35-1 Migrating WebCenter Portal to Another Target

Description of Figure 35-1 follows
Description of "Figure 35-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

  • Lightweight content - Images from the all portals’ content folder, styled text, and text.

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

In addition, the WebCenter Portal archive (.par 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 (.par 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, 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 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 Moving Connections Details from Staging to Production.

Information Always Exported and Imported

The following information is always included when you migrate WebCenter Portal to another target:

  • Security Policy

    • policy-store.xml: Application roles and permissions and portal roles and permissions

    • User role assignments

  • MDS – Shared / Portal Assets

    • Page Templates

    • Navigations

    • Resource Catalogs

    • Skins

    • Page Styles

    • Content Presenter Templates

    • Mashup Styles

    • Data Controls

    • Task Flows

  • MDS – Tool/Service Data: Notes

  • MDS –Tool/Service Metadata

    • Announcements

    • Discussions

    • Documents

    • Events

    • Lists (Definitions)

    • Notes

    • Mail

    • Pages

    • Portlets

    • Recent Activities

    • Resource Catalog

    • RSS News Feeds

    • Search

    • Tags

    • Worklists

  • MDS – Portal Customizations: Portal administration settings

  • MDS – User Customizations: Pages, task flows, and preferences

  • WebCenter Portal Schema – Data

    • Activity Streams

    • Portal Events

    • Feedback

    • Links

    • Lists

    • Message Boards

    • Profiles

    • Tags

    • People Connections: Default settings for profiles, message boards, feedback, connections, activity streams; Activity stream task flow customizations

Information Never Exported and Imported

The following information is never included when you migrate WebCenter Portal to another target:

  • External - Application Artifacts: icons and images

  • External – Tool / Service Data

    • Documents (on content server)

    • Wikis and Blogs

    • Activity Graph

    • Analytics

    • Announcements

    • Discussions

    • IMP

    • Mail

    • Personal Events

    • Worklists

  • Out-of-the -box: Portal templates and connections

Note:

Connections can be imported or exported based on options.

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

35.6.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 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 Moving Connections Details from Staging to Production.

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

    Note:

    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, 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 Backing Up an Entire WebCenter Portal Installation.

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

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

35.6.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 (.par 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 Understanding WebCenter Portal Back Up and Recovery.

This section includes the following:

35.6.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.
  2. From the WebCenter Portal menu, select Application Export (Figure 35-2).

    Figure 35-2 WebCenter Portal Menu - Application Export Option

    Description of Figure 35-2 follows
    Description of "Figure 35-2 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 .par filename contains a unique ID—webcenter_wholeapp_ts_unique_ID.par (Figure 35-3).

    Figure 35-3 Naming the Export Archive

    Description of Figure 35-3 follows
    Description of "Figure 35-3 Naming the Export Archive"
  4. Click Export.
  5. In the Download dialog (Figure 35-4), click Export to confirm that you want to go ahead.

    Figure 35-4 Downloading an Export Archive

    Description of Figure 35-4 follows
    Description of "Figure 35-4 Downloading an Export Archive"

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

  6. When the export process is complete, specify a location for the export archive (.par).

    Figure 35-5 Saving an Export Archive

    Description of Figure 35-5 follows
    Description of "Figure 35-5 Saving an Export Archive"

    Select one of:

    • Download - Saves the export PAR 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 PAR file to a server location.

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

      Ensure that the server directory you specify has write permissions.

      Figure 35-6 Archive Location

      Description of Figure 35-6 follows
      Description of "Figure 35-6 Archive Location"
  7. Click Close to dismiss the Export window.

The export archive (.PAR) 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 Viewing and Configuring WebCenter Portal Logs.

See also, Troubleshooting WebCenter Portal Import and Export.

35.6.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.par. It also exports connections to the connection.properties file.

wls:/weblogic/serverConfig>exportWebCenterApplication(appName='webcenter', 
fileName='myAppExport.par', connectionFileName='connection.properties')

The following example exports a test WebCenter Portal instance. The .par file is saved to the location from which you run the WLST command:

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

For command syntax and examples, see exportWebCenterApplication in WebCenter WLST Command Reference.

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

35.6.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 Prerequisites for WebCenter Portal Export and Import.

This section includes the following:

35.6.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.
  2. From the WebCenter Portal menu, select Application Import.
  3. In the Application Import page (Figure 35-7), specify the location of your WebCenter Portal archive (.par).

    Figure 35-7 Application Import Page

    Description of Figure 35-7 follows
    Description of "Figure 35-7 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 .par 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 Importing Portals from an Archive Importing Portals from an Archive for more information.

  4. Click Import.
  5. In the Application Import dialog (Figure 35-8), click Import.

    Figure 35-8 Application Import dialog

    Description of Figure 35-8 follows
    Description of "Figure 35-8 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 Verifying WebCenter Portal After Import.

35.6.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 importWebCenterApplication in WebCenter WLST Command Reference .

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

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

For information on how to run WLST commands, see 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 Verifying WebCenter Portal After Import.

35.6.4.3 Verifying WebCenter Portal After Import

After importing WebCenter Portal from an archive you must:

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

    In a cluster environment, restart each managed server in the cluster. See also, 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.
  3. Initiate the Oracle Secure Enterprise Search crawler to index newly imported data.

35.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.

Note:

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.
  2. Restore MDS schema data from a backup.
  3. (Optional) Restore Content Server data from a backup.
  4. (Optional) Restore discussion schema data from a backup.
  5. (Optional) Restore other schemas data for WebCenter Portal from a backup.
  6. Restore security store data from backups.
  7. (Optional) Restore connections for WebCenter Portal from a backup.
  8. (Optional) Restore audit configuration for WebCenter Portal from a backup.
  9. (Optional) Restore the WebLogic Server domain hosting WebCenter Portal from a backup.
  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 Using Scripts to Back Up and Restore WebCenter Portal.

35.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 back up requirements.

For more information, read the following topics:

35.8.1 Understanding Back Up and Restore Script Files

Oracle provides sample scripts to help automate your back up 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 35-2 describes the sample scripts and files provided for back up and recovery:

Table 35-2 Sample Scripts and Files for Back up 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 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 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 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 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.

35.8.1.1 master_script.sh

master_script.sh 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 

Note:

The expdp database command for individual schemas are described in 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 wlst_script.py.

The following is a sample master_script.sh script:

## 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.$$

35.8.1.2 wlst_script.py

The wlst_script.sh 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)

Note:

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

The following is a sample wlst_script.py script:

## 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
  disconnect() 
  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
  disconnect()
  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)

35.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 35-3 lists and describes the input parameters in backup.properties and restore.properties files.

Table 35-3 User Defined Parameters for Back Up and Restore Scripts

Back up / Restore Parameter Description Example

OPERATION

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

For back up:

export

For restore:

import

Database information

   

DATA_DIRECTORY

For back up 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 back up:

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 back up 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 back up 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 back up 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 back up 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 back up 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_Portal

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

The following example shows a sample backup.properties file with sample values.

## 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_Portal

## 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

The following example shows a sample restore.properties file with sample values.

## 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_Portal

## 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

35.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 Back Up Scripts (first time only).
  2. Complete Prerequisite Tasks for Security Store Back Up (first time only).
  3. Set Back Up Parameters and Customize Scripts (first time only).
  4. Run the Back Up Script.
  5. Verify Back Up Archives.
  6. Schedule Regular Back Ups Using the Scripts.

35.8.2.1 Create Back Up 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 the sample code for master_script.sh from 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 the sample code for wlst_script.py from wlst_script.py, paste into a text editor, and save the file as wlst_script.py in the same directory.
  4. Copy the sample code for backup.properties from backup.properties and restore.properties Files, paste into a text editor, and save the file as backup.properties in the same directory.

35.8.2.2 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.db"/>
      </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.db"/>
      </jpsContext>
      
      <jpsContext name="mytargetCred"> 
           <serviceInstanceRef ref="credstore.backup.xml"/>
      </jpsContext>
      

35.8.2.3 Set Back Up 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 35-3 for a description of each parameter.

    Note:

    You can comment out parameters that are not required.

  4. Customize the back up scripts, if required.

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

  5. Save the changes.

35.8.2.4 Run the Back Up 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 back up 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.

35.8.2.5 Verify Back Up 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 back up 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

35.8.2.6 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.

35.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. Restore Database Schemas Manually (first time only).
  3. Complete Prerequisite Tasks for Security Store Restore (first time only).
  4. Set Restore Script Parameters.
  5. Run the Restoration Script.
  6. Verify Restored Data.

35.8.3.1 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 the sample code for restore.properties from backup.properties and restore.properties Files, 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

35.8.3.2 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.

    Note:

    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.

35.8.3.3 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>
      

35.8.3.4 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 35-3 for a description of each parameter.

  4. Save the changes.

35.8.3.5 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.

35.8.3.6 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.

35.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 Additional Steps for Moving Oracle WebCenter Portal in Administering Oracle Fusion Middleware.