Server Configuration > File Vaulting for Configuration Management > Migrating Existing Revisions to the File Vault
Migrating Existing Revisions to the File Vault
You can extract eligible revisions from the PTC RV&S database, and move those revisions to the Configuration Management file vault in a single bulk operation. Eligible revisions include:
• revisions of binary archives
• revisions of text archives whose archive storage format is set to store by reference
When migrating revisions from the database to the vault, only the canonical archive location determines where revisions are stored. Consider the following example:
ProjectA is configured to store revisions in the file vault.ProjectB is configured to store revisions in the database.A subproject from ProjectA is shared to ProjectB as a shared subproject.
Because the canonical location of the shared subproject is in ProjectA’s hierarchy, the canonical archive location of members of that shared subproject are under ProjectA as well. The shared subproject's revisions are therefore stored in the file vault.
Migrating Existing Revisions to the File Vault
To migrate existing revisions into the file vault in the CLI:
* 
Administrators require the AdminServer permission to migrate existing revisions into the file vault.
* 
This optional one-time migration step is not bidirectional and may affect the system performance while execution. Once the PTC RV&S revisions are stored in the Configuration Management file vault, there is no way to move those revisions back into the database.
PTC recommends to backup the data before starting the migration.
1. Ensure that the file vault is properly configured, and that the file vault directory exists on the PTC RV&S server file system. For more information, see Configuring the File Vault.
2. Run the file vault migration command to migrate all eligible revisions in the repository to the file vault: si diag --diag="migrateRevisionsFromDBToFileVaultAsPerPolicy".
The migrateRevisionsFromDBToFileVaultAsPerPolicy diagnostic command has the following options:
• path specifies the configuration management project path to migrate to the file vault. If this parameter is specified, only eligible revisions from the specified project path are migrated. You can specify only a single project using this parameter. If this parameter is not specified, then all eligible configuration management projects are considered for migration.
* 
The project specified in this path parameter must have the Use File Vault for Store by Reference Member Revisions configuration management policy set. If the policy is disabled at the project level, then eligible revisions in that project are not migrated. For more information on setting configuration management policies, see the topic “To set general policies”.
The project path in this parameter must be specified as the canonical path of the project. For example, to migrate the demoMigrate project whose location is ProjectDirectory/demoMigrate/project.pj, then in the CLI, exclude /project.pj to specify only the canonical project path in the command syntax. For more information on specifying projects using a canonical path, see the CLI man pages.
• count specifies the maximum number of archives to be processed and migrated into the file vault. The migration attempts to move all of an archive’s revisions, and the oldest revisions receive the highest priority during migration.
• before specifies the server date and time after which revisions are not migrated.
For example, to migrate the 100 oldest demoMigrate revisions in the repository to the file vault, run the following command:
si diag --diag="migrateRevisionsFromDBToFileVaultAsPerPolicy"
--param=path="/demoMigrate" --param=count=100
To migrate all demoMigrate revisions with a creation timestamp before January 1, 2015 at noon, run the following command:
si diag --diag="migrateRevisionsFromDBToFileVaultAsPerPolicy"
--param=path="/demoMigrate" --param=before="2015/01/01 12:00:00"
* 
If no parameters are specified, then all eligible revisions in the system are permanently migrated from the database to the file vault.
After running the migration command, a migration summary displays as follows:
--------Archives Statistics--------
Migrated= , Skipped=
--------Revision Statistics--------
Migrated= , Failed= , Skipped=
Additional details, including revision statistics, are logged to the DB_to_FileVault_Migration.log file located under PTCRV&SServerinstalldir/log.
Migrating Older Revisions to the File Vault
You can migrate older revisions out of the database while keeping new revisions in the database. This special configuration mode requires you to leave the file vault property disabled, and to configure a valid file vault location. Then, you run the migration to vault eligible revisions. All newly created revisions are stored in the database.
To migrate only legacy revisions to the file vault:
1. Stop the PTC RV&S server.
2. In the si.properties file under PTCRV&SServerinstalldir/config/properties, specify the vault location using si.vault.location=, and ensure that vault support is disabled as follows: si.vault.enable=false.
3. Start the PTC RV&S
server.
4. In the PTC RV&S Administration Client, enable the Use File Vault for Store by Reference Member Revisions configuration management policy globally or for a specific project.
5. Run the file vault migration command si diag migrateRevisionsFromDBToFileVaultAsPerPolicy. Include the path option if vaulting a specific project, and include other supported options as needed, such as the before option.
After migrating legacy revisions to the file vault, you can remove the Use File Vault for Store by Reference Member Revisions policy if you do not plan to migrate additional revisions later.
* 
To migrate older revision data when the file vault is already enabled, disable the file vault temporarily and enable the Use File Vault for Store by Reference Member Revisions policy for the project you want to vault. Then, run the migration command for that project. Following the migration, remove that policy and re-enable the file vault to resume vaulting of new revisions.
* 
To reclaim the space previously occupied by the data that was migrated to the file vault, database shrinking is required. For further assistance, contact your Database administrator.
Was this helpful?