-
Title
Proc and Alert logs show "Database backup sets" being locked -
Description
Proc and Alert logs show "Database backup sets" being locked
error message is "Unexpected exception while removing C:\Quest\Repos\DatabaseBackupSet\000765fe0000021a-0001-2.5.916.1184-tpam.log.zip:
The process cannot access the file ' C:\Quest\Repos\DatabaseBackupSet\000765fe0000021a-0001-2.5.916.1184-tpam.log.zip' because it is being used by another process."
-
Cause
If the TPAM appliance is changed from "Appliance Active: Active" to "Appliance Active: Not Active" on the slow-link Replica the alert logs stop sending the Moderate warning that 'primary server name (ip address of primary) caught and unexpected exception while performing task Removing 1 files from Database BackupSet://(ip address of slow link replica): Repository is write protected.
-
Resolution
Considering the value of the information stored in TPAM the backup engine is an integral part of TPAM. Backups can be configured to run automatically and moved securely to offline storage. If PSM sessions are being recorded on the appliance and they are not sent to an archive server the TPAM backups can get extremely large. It is recommended to send session logs to an archive server to avoid this.
In the /admin console navigate to Backup Management | Settings | Schedule
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Those "write protect" errors are quite common when the primary is transferring a large file over a slow link. They are okay as long as the file size comparison is changing indicating progress. Setting the cluster member to Not Active should prevent the primary (and other devices eventually) from sharing status information and the primary should stop replicating to it, but that may require restarting the cluster state machine of the primary using Restart Clustering button.If the primary is transferring a large file it would continue even after "Restart Clustering" unless that process terminates the transfer or the transfer times out. It is not expected for a reboot to fix a slow link. It is typically suggested to initiate the replica reboot and then the primary reboot to maximize the time overlap while both are restarting.