How to Scan the Storage for Leaks

This article presents the usage of the SCAN ALL command for the purpose of detecting and eventually purging storage leaks.

Solution

A storage leak is defined as a message existing within an Axigen message storage, which is not referred from any mailbox.

  1. Typical usage of the SCAN ALL command

    A typical usage of this command involves 2 steps: the storages are first scanned for leaks without enforcing any specific action. If the result of the fist scan indicates any significant leaks, they may be purged by running the command again using one of the purge arguments (purge or softPurge).

    The scan process is using a persistent cache, so that the second iteration (issued after analyzing the current status) will execute faster. The cache that is built expires after one week.

    The syntax of this command is:

    SCAN ALL [purge|softPurge][verbose][readOnly][imapLeaks][cachedOnly][clearCache]

    In order to scan the storage for leaks, you will need to use the CLI interface. In order to connect to the CLI interface you can use telnet:

    telnet 7000
    user admin
    your_admin_passwd
    For a list of available commands, type HELP
    +OK: Authentication successful
    <#>

    After successfully authenticating, you can enter the domain's context:

    <#> UPDATE Domain name
    +OK: command successful

    Now use the SCAN ALL command in order to scan the domain's message storages for leaks:

    scan all

    During the scan process, partial results are displayed every 15 seconds. However results are likely to change during the process, as links to the messages are found, and only the final results should be considered when deciding if you need to purge the leaks or not. Below is an example of how the final scan results may look like:

    count size meta size total size Messages : 195633 28.674 GB 26.324 MB 28.700 GB RmMessages : 0 0 B 0 B 0 B Properties : 5740 14.316 MB 486.219 KB 14.791 MB RmProperties : 0 0 B 0 B 0 B Leaks : 59 4.592 MB 9.011 KB 4.601 MB Soft leaks : 1 0 B 101 B 101 B Possible Leaks: 0 Cache size : 196960 messages in 226 mboxes Elapsed time : 14.6 minutes Total : 201433 28.692 GB 26.807 MB 28.718 GB

    The decision whether to purge the leaks or not should be based on the "count" and "total size" values corresponding to the "Leaks" category.

    If any significant leaks are found, you may purge them using the following command:

    scan all softpurge
  2. Understanding the command's output and arguments

    The output of the command contains some storage parameters. Some of them are not related to leaks and therefore not relevent in the context of this article.

    The categories from the command's output have the following meanings:

    Messages - email messages, Calendar items, Taks, Notes, etc.
    RmMessages - messages for which a deletion was requested by the users but were not yet actually processed in the storage by the deletion job
    Properties and RmProperties - Message properties (mainly MAPI properties) and respectively MAPI properties pending deletion in the storage
    Leaks - messages found in the storages, which are not referred from any mailbox
    Soft Leaks - leaks which were already soft purged in the past
    Possible leaks - this is a temporary parameter indicating messages for which a reference was not yet found. The value may be non-zero only in the partial scan results
    Cache size - the current size of the runtime (non-persistent) cache

    The possible arguments for the SCAN ALL command are explained below:

    purge - remove the identified storage leaks
    softPurge - truncate the identified storage leaks to 0 bytes. As a result they will no longer consume any space in the storage.
    verbose - produce more verbose output
    readOnly - do not save the SCAN cache into the storage
    imapLeaks - treat incomplete messages larger than 4kB as Leaks (only if the last 4kB of the message contains only 0's)
    cachedOnly - rely only on the existing persistent SCAN cache (do not perform any real-time scanning)
    clearCache - clear the persistent SCAN cache
  3. Notes and other considerations

    The scan process may take a significant amount of time, depending on storage size and storage access speed. If the process needs to be stopped for any reason, the following command may be used:

    SCAN abort

    If the telnet CLI session terminates due to a timeout before the command finishes, the scan process continues in the background. In this circumstance, you can open a new session and attach or observe the state of the operation using the command:

    SCAN attach | peek [timeout]

    If needed, you may scan the message storages individually. To do this, you first need to obtain a list of the Unique Storage IDs (USIDs) of the storages using the command:

    LIST storages

    To scan a specific storage use the command:

    SCAN Storage usid [usid ...]

    For example:

    SCAN storage usid 02-00-1A6F-5B75B02F-AFBFE0EA

    Note:

    Only message storages (USID starting with "02-") may be scanned.

OS: LinuxWindows