Written by: Bryce Hooper, Application Engineer, DASI Solutions
There are several methods that are capable of reducing the overall footprint of our vault on a hard drive. Here we will discuss 2 methods: Compression and Cold Storage. As noted below, each of these has their own benefit and caveat. It is important to keep this in mind before implementing either solution.
By default, all versions of files stored in the archive are stored in an uncompressed format. To save some space, it is possible to enable compression on all versions that are not the latest. This process will, per a schedule, check the archive and compress any files into a .GZ compressed archive.
Adding compression to your vaults is best done through group policy, though there is a manual method to enable for only specific vaults.
Note: For vaults that have been compressed, there is no option to undo the compression. Turning the option off will prevent further files from being compressed but will not change already compressed files. It is also of note that, due to formatting changes in SOLIDWORKS files, compression is not as beneficial as it once was. However, it is still potentially useful for other file formats that you may be storing in the vault.
Group Policy Compression
On the archive server, launch the Group Policy Editor dialog by going to the Start Menu and searching for ‘gpedit’.
In the resulting dialog, expand Computer Configuration and right click ‘Administrative Templates’ in the left pane. Select the menu option to ‘Add/Remove Templates’. Click the ‘Add’ button to load a policy template. Navigate to your SOLIDWORKS installation media then to \SWPDMClient\Support\Policies and select ‘PDMWorks Enterprise.ADM template’. This policy is now available under the Administrative Templates category. Expand this folder, then Classic Administrative Templates (ADM) and SOLIDWORKS PDM Settings to select Archive Server. The Archive Compression Setting can be right clicked and edited.
Set the radio button to Enabled and specify a schedule. Compression will compress any files in the archive that are not the latest based on this. It is recommended that this process not be too frequent to avoid taxing the server during peak hours. All vaults on this archive are going to be compressed. To make the compression vault specific, you must use the manual method.
Vault compression may be configured per vault if it is not configured per Group Policy. To do this, we must create a string value registry key named CompressionSchedule located at:
|HKEY_LOCAL_MACHINE\SOFTWARE\SolidWorks\Applications\PDMWorks Enterprise\ArchiveServer\Vaults\[Vault Name]|
The value of this key follows the same structure as both the group policy schedule and the Cleaner Service schedule as detailed above.
Cold Storage Schemas
Cold Storage is a two-fold discussion as it has two potential setups that may help. Cold Storage has the ability to relocate some older versions of files, and it has the ability to clean out some ‘unnecessary’ old versions of files as well.
Note: In either schema setup, there is no definitive way to determine how much data will be (re)moved ahead of running. All changes in both cases are permanent.
Cold Storage – Relocate
The primary intended function of Cold Storage is to relocate old versions of files to a secondary location for permanent storage. To do this, the configuration requires which folders should have this effect and by what schedule files should be moved, along with a path to move them to. The path must be accessible by the archive server.
The above example is putting all versions of files older than the last 10 (but not demarked as a revision) into the store. The store is going to the D: Drive filed under Year\Month\Day and is processing them every day at midnight. The entry under “Media Name” will be noted in the history as the location for the cold store.
If we have a networked location or secondary drive that would work well for this but not for relocation this may be an option.
Notes: While this process does move data, in some cases it can actually create additional data and take up more space than before. Files that go into the vault are assessed on whether or not the data in the file has changed or whether meta-data in the database has changed. If the file has not changed, the archive does its best to minimize the footprint of each file and will reference the same file for different versions. When cold storage processes a file for a version that did not explicitly have a unique file, it will copy that file and place it into a compressed package. This, in turn, has now created a second copy of a file that the archive had already determined not to be unique. In this way, we have made the issue of space worse.
The scheduling for cold storage is set on the same system as previously described under the cleaner service schedule section above.
Files that have been cold stored require additional permissions to access. If a user does not have permissions, and attempts to get an older version of the file, the latest version will be used and a warning will be displayed.
In the event of a rollback, it is also impossible to roll back to a point that was before a cold stored version. Cold Stored files are compressed and moved, there is no way to reverse this change.
Cold Storage – Deletion
The secondary function of the Cold Storage schema is to delete older versions beyond a defined point. The setup to this is similar to that of the relocation schema, but differs in that we do not need a path for a deletion. Simply change the radio button to indicate that the schema is for deletion and specify the number of versions to maintain and whether or not versions marked as revisions will be saved as well. The process will run on the determined schedule and remove any version of a file beyond the specified point. All removals are permanent and cannot be reversed. This is noted in the history and versions previous to the deleted versions cannot be rolled back to similar to the relocation schema.
Before taking any steps to relocate, remove, or compress data, please ensure that all files have been checked in by the users, backups have been taken of both the database and archives. In the event of a relocation, have all users log off or go into Offline Mode before attempting the move.