Managing Revaulting

Enterprise Administration > File Vaulting and Replication > File Vaulting > Understanding File Vaulting > Managing Revaulting

Managing Revaulting

When a vaulting rule is created, modified, or deleted, the files must be relocated to their new home. This process is called revaulting.

Revaulting is necessary when a vaulting rule is modified to use another file vault or when a vaulting rule is deleted, which is equivalent to designating the object storage to be in a BLOB. Revaulting may also be needed when a change occurs in the domain or life cycle state of an object that holds content files. The revaulting process for such object changes can be done in the background, which is administered by the wt.fv.revaultOnChange property. The default setting for this property is true.

If you are not setting properties through a graphical user interface or in a mapping rules file, you add or edit properties with the xconfmanager utility. For more information, see Using the xconfmanager Utility.

Revaulting can be a resource-intensive activity, and therefore it needs to be managed. To designate a vault for revaulting, you must create a schedule to specify when it will take place. At the scheduled time, the revaulting process launches and the contents of the vault are automatically relocated to another vault, moved from a vault to BLOB storage, or moved from a BLOB to a vault. Use the Remove unreferenced files option, available from the Vault Configuration window, to clean up the vault storage after the revaulting process.

The task of managing revaulting is primarily the routine of scheduling when the revaulting should occur for each vault and then periodically monitoring its progress.

Examining Existing Revaulting Schedules

Before creating, modifying, or deleting existing revaulting operations, you may want to examine the existing schedules. You can do this on the External Storage Scheduling window. This window displays a list of vaults for which revaulting has been scheduled, along with the frequency, time of the next revaulting process, and status of the current revaulting run. A status of Ready means that the run has been scheduled.

For information about accessing the External Storage Scheduling window, see Scheduling External Storage.

Viewing the Results of Revaulting

To review the results of the revaulting operations, select a revaulting schedule on the External Storage Scheduling window and then click Log. The Revaulting History window opens. This window displays the vault, the time that the revaulting run request was submitted, that the revaulting run was completed, and the execution status of all revaulting runs.

In certain cases, because of the way data is configured, not all of the objects to be revaulted are included in a single revaulting run. This can occur when two different content holders share the same vaulted content through separate application data entries. In this case, both content holders are not picked up for the same revaulting run. When this occurs, the remaining objects are picked up in the next revaulting run.

Following are tips for scheduling revaulting:

• The completion time of a run should be earlier than the submission time of the next revaulting run. If this is not the case, you should increase the period length to prevent this overlap.

• Revaulting should occur on a regular basis. Because it can be a resource intensive operation, PTC recommends that revaulting be scheduled for a time period with the least system activity.

A revaulting schedule can begin immediately (Immediate) or on a schedule that you determine (On Schedule), and it can occur one time (Once) or periodically at the interval that you specify (Periodic). It is recommended that you set revaulting to occur periodically and at a date and time that you specify. Use the On Schedule and Periodic options to accomplish this.

Forcing Content to Vault

With the increasing capability of certain applications comes a possibility that the increased number of vaults and file vault policy rules may become unmanageable. You can use the wt.fv.forceContentToVault to control this. If this property is set to false, which is the default setting, it has no effect. If this property set to true, the property forces vaulting to be accomplished through a single vault in the following way:

• The method server does not start if more than one main vault is present in the system. Therefore, you need to remove all main vaults but one before enabling this property. A message appears in the method server log describing the problem.

• If users attempt to create more than one main vault, they receive an error message stating that they cannot create more than one main vault.

• If revaulting is scheduled on the existing vault, all content that can be vaulted is moved to this vault.

• When content is uploaded to the main vault, all content that can be vaulted goes to the existing vault. Therefore, this vault must be designated as the cache vault.

A write-enabled cache vault is required to create a document or CAD document in Windchill.

• File vaulting policy rules are ignored.

Avoiding Storage of Content in BLOBs

Forcing content to a single vault increases performance by preventing content files from being stored in BLOBs, and also reduces the need for a proliferation of vaulting rules.

When you use file vaults, the database and file system backups are no longer synchronized. Vaulting is recommended only in situations where the storage is fault-tolerant, such if RAID or mirroring is used, to minimize the risk of data loss if a single drive fails.

Converting from Multiple Vaults to a Single Vault

To convert from a multiple-vault to single-vault external storage configuration:

1. Delete scheduled revaulting entries.

2. Use the following SQL statements to delete existing revaulting rules:

delete FvPolicyRule
delete FVPolicyItem

3. Reassign all storage folders to your target main vault.

4. If there are any vaults with Auto Folder creation set, then create vaulting rules to move data from these vaults to the target main vault.

5. Initiate revaulting to the target main vault so that any remaining data is moved from vaults with Auto Folder creation set to the target main vault.

6. Delete all vaults except the target main vault.

7. Add the following to the wt.properties file:

wt.fv.forceContentToVault=true

8. Restart the method server.

9. Ensure that the target main vault is properly configured for a large number of data sets by adding, for example, 100 folders.

10. Initiate revaulting to the target main vault so that any remaining data is moved from BLOBs to the vault.

Revaulting and the wt.fv.useVaultsForAllContent Property

The following property affects revaulting:

wt.fv.useVaultsForAllContent

The default setting for this value is false. If you set this value to true and revaulting is scheduled on a vault, the following happens:

• All content in this vault for which the rules have been defined with a different vault as the target is moved to its target vaults.

• All content in all other vaults for which the rules have been defined with this vault as target is moved to this vault.

• All content in this vault which has no rules defined is sent to the default target vault for the site.

• All content in BLOBs for which the rules are defined with this vault is moved to this vault.

• If the vault on which revaulting is scheduled is the default target vault for the site, all content in BLOBs for which no rules are defined is moved to this vault.

This only happens once. As with this setting, all uploaded content for which no rules are defined is stored in the default target for site. Every site must have a vault that is the default target for the site. If a vault that is a default target for a site already exists and you select a new vault, the new vault becomes the default target for the site rather than the existing one.

Was this helpful?