This chapter contains information about backing up and restoring the Oracle Communications Design Studio application, Design Studio projects, and Design Studio archives. Additionally, it describes a typical backup and restore strategy.
Backing up Design Studio requires the following:
Back up the Design Studio application. See "Backing-up the Design Studio Application" for more information.
Back up Design Studio Projects. See "Backing Up Design Studio Projects" for more information.
Back up Design Studio run-time archives. See "Backing Up Design Studio Run-Time Archives" for more information.
To ensure that the Design Studio application is not lost, archive each individual component as well as the assembled application environment.
Recommended frequency: Once per Design Studio release
Backup type: Manual
Recommended tooling: ZIP or TAR file
The application resources include any file required to run the Design Studio user interface or command-line builds. Back up the following application components:
Oracle Enterprise for Eclipse package
Design Studio feature TAR files
Complete Design Studio environment
Design Studio build scripts and configuration files
Source control system application
Back up the complete Design Studio environment in ZIP or TAR format, and use the same archive to distribute to individual Design Studio users. See Design Studio Installation Guide for more information about distributing preconfigured installations.
Back up Design Studio project data files with every revision. Oracle recommends that you back up project data files using source control. See "Using Source Control to Back Up Design Studio Projects" for more information.
Recommended frequency: Daily
Backup type: Automated
Recommended tooling: Source control system
Backup the project folder, except for the following resources:
Note:
Do not place the following resources under source control..metadata workspace folder and subfolders
Java bin folder and subfolders
cartridgeBuild folder and subfolders
doc folder and subfolders
Unsealed cartridges in the cartridgeBin folder
You can generate the content of a Design Studio project cartridgeBin folder (in unsealed cartridges) at any time. However, Oracle recommends that you define a production deployment archive strategy for run-time artifacts that is separate from project backups. See Design Studio Installation Guide for more information.
Include the cartridgeBin folder (for sealed cartridges) in backups and source control because run-time artifacts are not regenerated during sealed cartridge builds.
Oracle recommends that you use a source control system for backing up Design Studio projects. Design Studio includes support for the Eclipse platform Team functions, which enable Design Studio to interact with source control systems when managing resource changes in your projects.
Oracle recommends that you automate source control system backup. Automating this function to run daily ensures that a recent copy of the system is available at all times. Automated backups used in conjunction with regular user check-ins minimize potential data loss. Source control systems include complete sets of revisions for all files and folders, so maintaining multiple versions (Oracle recommends one week of versions) of the source control system backup is sufficient for redundancy.
Eclipse includes support for the Concurrent Versions System (CVS) programming environment, and additional plug-ins are available for other source control systems. For information about using Eclipse for CVS source control, see the discussion about team programming with CVS in the Eclipse Workbench User Guide. For information about what to source control in Design Studio, see Design Studio Developer's Guide.
Design Studio creates run-time archives whenever individual Design Studio users build projects. Back up run-time archives to ensure repeatable production deployments of release versions.
Recommended frequency: Every milestone cartridge build
Backup type: Manual or automated
Recommended tooling: None required
Oracle recommends that you back up the Design Studio run-time archives that are used in the production deployment process. To back up the run-time archives, retain a copy of the cartridgeBin folder content of each project following a full command-line build. You can automate this backup by incorporating it into Design Studio command-line build scripts.
Note:
Design Studio produces run-time archives during the build process. These archives are saved to the cartridgeBin folder of the corresponding project. Design Studio produces run-time archives only for projects that represent a deployable cartridge. Projects that do not represent deployable cartridges (for example, Model projects) do not produce run-time archives.See "Automating Builds" for more information.
Restoring Design Studio requires the following:
Determine which type of recovery to use. See "About Data Recovery Types" for more information.
Select a general strategy for data recovery. See "About Data Recovery Strategies" for more information.
Restore the Design Studio application. See "Restoring the Design Studio Application" for more information.
Restore Design Studio projects. See "Restoring Design Studio Projects" for more information.
Restore Design Studio run-time archives. See "Restoring Design Studio Run-Time Archives" for more information.
There are two primary forms of data recovery, file media recovery and complete recovery.
Use file media recovery when your individual Design Studio users must recover from a lost file, a damaged file, or from accidental or unintended file changes. You can perform file media recovery using source control or user-managed backup and recovery.
The first step in performing file media recovery is to manually restore the file by copying it from a backup. Once you restore a file from a backup, Oracle recommends that you refresh the file in Design Studio to ensure that the application is using the current file and not a cached version. If using a source control system, you can recover the file using the source control system synchronization functions.
Use complete recovery to recover from accidental or unintended file changes. You can perform complete recovery whether you use source control or user-managed backup and recovery.
Your approach to data recovery depends on whether the failure is media failure or user error, and the nature of the specific failure.
Strategies for Responding to Media Failure
Returning a system to operation following media failure depends on your backup strategy. In all cases, maintaining copies on multiple physical devices is critical. Recovery from backups stored on the same physical device may be possible if media failure is localized to a file or folder of the file system. However, the best protection strategy ensures data is always available on multiple physical devices in different physical locations.
Because it is often difficult to determine the files affected, a complete recovery is generally the best strategy to recover from media failure.
Strategies for Responding to User Error
User error failures require one of the following responses:
Re-import the deleted file if a suitable copy or a previous version of the file exists.
Re-enter the lost data manually if a record of data exists.
Discard local changes and return the project to a previous state using source control.
Your backup strategy determines the recovery options that are available to you. For example, if you have no source control system, you have limited choices for restoring content to a particular point-in-time. Perform file media recovery if you can determine the files affected by the user error. Otherwise, perform a complete recovery.
You must restore the Design Studio application to recover from a corrupted installation. To restore the Design Studio application, you instruct individual Design Studio users to do one of the following:
Obtain and unzip a new prepackaged installation (that you provide).
Reinstall the application using backups of any previously downloaded archives.
See Design Studio Installation Guide for more information.
You can recover from a loss in a Design Studio project using file media recovery or complete recovery. The method you use depends on whether you can identify the affected Design Studio data files.
If the affected files are few and easily identified, use file media recovery. When restoring project data using file media recovery, you can instruct individual users to:
View local history for Design Studio resources.
The Eclipse Local History feature recovery is a form of file media recovery that employs the use of the application's file history feature. The application can be configured to maintain copies of previous versions of a file. The local history of these files can be examined and used to replace or correct a current version. Source control implementations also include file versions committed to the repository to provide a complete file change history. For more information about the CVS History view, see the Eclipse Workbench User Guide.
Replace versions with local history or source control revisions.
You can replace the current version of a resource with a revision from local history or source control using the CVS History view. See the Eclipse Workbench User Guide for more information about replacing a resource with local history.
Restore deleted files.
See the Eclipse Workbench User Guide for more information about restoring deleted resources from local history.
Prior to performing a complete recovery, make a local backup of the corrupted project files. You may require this backup to recover content that was not present in the backup and is not easily reproducible.
Perform a complete recovery in a clean file structure (and not in an existing project) to ensure that old files are not included with the recovered content. If erroneous content can be isolated to specific projects, then recover those projects in their entirety. Otherwise, recover all projects in a new workspace.
When restoring project data using complete recovery, you can:
Restore project data from a source control repository.
The steps to recover a project from a source control repository vary by source control provider. For information about recovering projects when using CVS, see the Eclipse Workbench User Guide.
Restore project data from a local backup.
You can instruct individual users to restore Design Studio projects from a local backup. This approach may be required if you are not using a source control system or if the project requiring recovery has not been committed to source control but a local backup has been made.
The local backup can be in archive format (ZIP or TAR) or can be a copy of the project folder in a different location. See Design Studio Help for information about importing projects.
To restore a workspace, you can instruct individual users to:
Delete the .metadata folder to clear an existing workspace. A new workspace is created the next time Design Studio is launched.
Import workspace preferences to a new workspace if they were previously exported for backup. See Design Studio Help for information about retaining workspace preferences.
If the source control repository is compromised through user error or media failure, it may be necessary to revert the repository to a recent automated daily source control repository backup. Use the source control system documentation to recover the backup of the source control repository.
Check that recent commits are present in the recovered source control repository. The repository will not include any committed content since the backup was made. Recover recent revisions from local history and reapply them to the repository to bring the repository up-to-date.
You can restore run-time archives by:
Reverting to a backup of the archive
Reproducing the archive
Reverting to a Run-Time Archive Backup
The backup of the run-time archive is an exact copy. To restore the lost file, copy the cartridge archive from the backup repository to replace a missing or corrupted archive.
Reproducing a Run-Time Archive
When a backup of the archive is not available, you must rebuild the archive using the Design Studio projects. Recover the project versions for the milestone build from the source control repository to provide a point-in-time view of the related projects. This point-in-time view can be identified by a repository tag indicating a branch, version, or date. The choice of tag to restore to is dependent on the repository branch strategy. Oracle recommends that the tag and branch strategy include version tagging for any milestone build.
After projects needed to produce the archive are restored from the source control repository, you can initiate a build to reproduce the cartridge archive.
See "Automating Builds" for more information.
Table 2-1 describes a typical backup strategy that you can use as an example when setting up your own backup strategy.
Table 2-1 Typical Design Studio Backup Strategy
| Resource | Frequency | Details |
|---|---|---|
|
Design Studio Components |
Archive every Design Studio release |
Copy each installation component to the backup file storage. ZIP the final installation and copy to the backup file storage. |
|
Source Control System Components |
Archive every Source Control System release |
Copy each installation component to the backup file storage. |
|
Design Studio Data Files |
Back up continuously |
Back up every revision with local history. Keep files for 28 days. Track every committed data file change using source control. |
|
Command Line Build Scripts |
Back up continuously |
Manage build script modifications using source control. |
|
Source Control Repository |
Archive Daily |
Automate backup of the source control repository to the backup file storage. Maintain 7 recent versions. |
|
Project Data Files |
Archive every project milestone |
Clean all projects. Export projects to an archive. Manually copy archive to the backup file storage. |
|
Design Studio Run-time Archives |
Archive every project milestone |
Tag the build in the source control system. Branch if desired. Manually copy build archive to the backup file storage. |
|
File Storage |
Back up continuously |
Automatically replicate file storage using RAID. Replicate storage to a physically separate location. |