Archive Management

You can manage Zoom archive and restore operations to move content from online to offline storage (such as LTO, Cloud-based e.g. Amazon S3) as well check on the statuses of assets in the repository from the Web-based Administration Console.

Make sure you have the appropriate license and have configured the archive location as shown in the post here: Configuring Archive Location

Archive Management Interface

Login to the Web-based Administration Console from a browser. (Typically this will be at http://zm-server:8443). From here, click on any option under the “Archive Management” section from the left-side navigation panel.

From this window, you will be able to –

  1. Invoke archive or restore operations upon the assets shown in the tree.
  2. Easily view the status of an asset on the repository as to whether it is alive or deleted or archived or renamed or moved. This status is made available visually through different styles for each state as well as through tooltips.
  3. View the progress on any ongoing archive or restore operations.
  4. View / approve / reject one or more petitions from the list of pending petitions. (Restore petitions are requests made by end users asking the administrators to restore certain archived assets).

Archive Health Check-up

In Zoom 5.2 or greater, you can also run data integrity checks on the archived assets.

  • Click on the “Archive/Restore Assets” option on the left-side panel
  • Select one or more archived assets from the tree shown there.
  • Click on the “Health-Check” menu at the top bar.

This option provides information about the current state of the archived files and notifies if some of the archived assets (if any) are corrupted.

A user with a minimum of EDIT_ALL permission within the target project will be allowed to commence
archive and restore operations.

Latent Archival, Active Restore

DAM repositories usually contain large amounts of data and archive/restore of these will usually take a long time. It is important to not let these operations hog the server making it unavailable to the end users for unreasonable intervals.
Zoom works around this issue by queuing up the archival requests and executing the actual file-data handling to a background process that runs at the time of server startup only. Therefore the core archival is latent and confined to server startup interval.

During this interval, no restore requests will be serviced.

As administrators can schedule periodic automatic server restarts at convenient intervals (usually around the time the server is least used, like weekends or midnights) the data-archival can proceed without disturbing the users.
On the other hand, the restore operations are active and immediate. This is because an archived asset is restored usually to have immediate access to the file data and that requirement must be met with.

Progress Monitoring

The progress of the file-data handling associated with the core-archival (that happens during the server start-up phase) and the restore operations can be monitored from the “Progress Report” option available under the “Archive Management” menu in the web console.

Note that this page will only report ongoing operations. A successfully completed operation will be
removed from this page. Any errors that may happen will be logged separately.

Error Tracking

Archive or restore operations may run into errors if there are permissions issues corresponding to the target disk locations or if the disk is full etc. Such errors are logged and the administrator can view them in the “Archive/Restore Errors” option in the web console.
Take a look at the screenshot below. This was taken after we generated an error by removing the source file from the Zoom database and then attempting an archive operation on that target file. As you see, the error report contains details like what was attempted (whether archive or restore), the time of the request and the file name of the asset that failed.

Data Integrity

Archive and restore operations are carried out with checksum verifications implicitly. If there is a checksum mismatch (which could happen if someone tampered with the file data), an alert is issued and the administrator must check the logs to get the details of the problem.

Fixing the Errors

If a particular asset is queued for archival but fails during the core archival at the time of server restart, the asset is left in the archive queue and will be attempted upon next time the server restarts. If it were a case of temporary glitch (like temporary network unavailability if the archive location is in a network share etc.) then the archival process will complete transparently at subsequent server restarts.

If however there is a genuine error, say, if someone deliberately removed a file from the Zoom database, in such cases repeated server restarts will not see the problem fixed. In such cases, Zoom has a way of turning off archival temporarily and resolving the issue.

As this is a slightly more involved process, this feature has not been exposed in our web console settings. Should you run into such issues, please contact Zoom support and we will guide you through the steps required to resolve them.

Notifications

Every archive and restore operation is followed by email notifications containing relevant details like the list of assets involved etc. The notifications will be sent to the super admin users and also the project admins who govern the project to which the target assets belong.

Restore Petition Management

Apart from the regular archive and restore operations, Zoom also sports a unique restore-petition operation which is very useful for end users who do not have enough permissions to directly restore an asset.

A restore petition is only generated if a) size of data restore exceeds the threshold (should be set to > 0 bytes)  b) user’s role has permissions below EDIT_ALL. For users with permissions EDIT_ALL or higher, the Archive module will do an instantaneous restore operation.

Approving or Rejecting Petitions

The restore petitions will be listed in the admin console for the administrator to examine. He/she can then either approve (in which case the asset will be restored) or reject (in which case the asset will remain archived) the petitions. To view the restore petitions, open the “Approve/Restore Petitions” option from the “Archive Management” menu of the web console. On clicking upon a petition, you can see the tree of assets that are being petitioned for.

You have the flexibility to either, approve/reject an entire petition or cherry-pick specific assets from the tree on the side and approve/reject only the selected assets.

The petition list will show details of the petition like the name of the petitioner, when the petition was invoked, the total size of assets that are being petitioned for restore etc. and also the tree of all the assets involved in each petition aiding the administrator to decide whether to approve or reject the petitions.

Notifications

When a restore-petition is issued, an email notification is sent to the super admin and the project admins who govern the target assets. Also, when a petition is approved or rejected, the petitioner is notified of the status of his / her petition.

Project-level Archive Handling

You could archive or restore an entire project from the Web Management Console. This will cause all the assets in the project to be archived or restored correspondingly.

Leave a Comment