--- title: "Aerospike Shared-Memory Tool (ASMT)" description: "Guide to the Aerospike Shared-Memory Tool (ASMT) for enabling warm restarts by backing up indexes across reboots." --- # Aerospike Shared-Memory Tool (ASMT) > For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt) > > All documentation pages available in markdown. The Aerospike Shared-Memory Tool (ASMT) backs up and restores Aerospike shared memory segments to disk, enabling warm restart across reboots in an Aerospike Database Enterprise Edition (EE) cluster. The tool backs up primary indexes, secondary indexes, and data stages from the server node (host machine) memory to the file system. After the backup, the server node can reboot without the time-consuming stage of rebuilding the indexes. ::: note This tool is not intended for namespaces where the primary index is configured on Persistent Memory or Flash (SSDs), as those would persist upon an instance restart. ::: ASMT needs a window between the shutdown of `asd` and the reclamation of its memory, and a container does not provide one. To warm restart across a container replacement, use the [index checkpoint](https://aerospike.com/docs/database/manage/database/index-checkpoint), which does the same copy from inside `asd`. It is available in Database 8.2.0 and later as an Enterprise Edition preview feature. ASMT remains supported for host reboots on bare metal and virtual machines. ## Warm restart with `asmt` Use the following steps to perform a warm restart of an Aerospike Database cluster node when planned maintenance includes a host reboot or power cycle: 1. Cleanly shut down the Aerospike cluster node process (`asd`). 2. Use `asmt` to copy the node’s indexes from shared memory to the local file system. 3. Perform maintenance on the server, then reboot or power cycle the host. 4. After the server restarts, use `asmt` to restore the indexes from the file system to shared memory. 5. Start `asd`, which will warm restart the node because the primary index is in shared memory. ### Multi-node maintenance If you are maintaining more than one node: - AP namespaces: After the node rejoins, wait for migrations to complete before working on the next node. This is especially important for in-memory namespaces without persistence, where data is lost on host reboot. In Database 4.3.0 and later, use [`cluster-stable`](https://aerospike.com/docs/database/reference/info#cluster-stable) to check status. It returns `ERROR` while migrations are in progress. For the full host-reboot workflow, follow [Planned maintenance with host reboot](https://aerospike.com/docs/database/manage/cluster/quiesce-node#planned-maintenance-with-host-reboot). - SC namespaces: Follow the [SC planned maintenance procedure](https://aerospike.com/docs/database/manage/cluster/consistency#planned-maintenance). You do not need to wait for migrations between nodes, but the handoff must complete before you shut down the next node. The alternative – a cold restart – is a much longer process because it requires the Aerospike cluster node to scan all storage devices to reconstruct the primary index. ::: caution You cannot use ASMT while `asd` is running. ::: ### When not to use ASMT In some situations a [cold restart](https://aerospike.com/docs/database/manage/database/cold-start) is preferable to restoring indexes with ASMT: - **Suspected memory corruption or DIMM maintenance.** If the host reboot is due to faulty or suspect DIMMs, restoring indexes from those shared memory segments may reintroduce corrupt data. Let the node cold restart so it rebuilds the indexes cleanly from storage. - **Reclaiming shared memory after cluster expansion.** When nodes have been added to the cluster and data has rebalanced, existing nodes may hold oversized shared memory segments from their previous partition ownership. Skipping ASMT and allowing a cold restart lets the node reallocate shared memory based on its current data footprint. ## Avoiding cold restart side effects During planned maintenance that involves a host reboot, shared memory segments holding the primary index are wiped. Without ASMT, the subsequent Aerospike startup is a [cold restart](https://aerospike.com/docs/database/manage/database/cold-start), which rebuilds the primary index by scanning data storage. This rebuild process can resurrect deleted records as [zombie records](https://aerospike.com/docs/database/manage/namespace/retention#avoiding-zombie-records). Using ASMT to persist and restore the primary index across the reboot ensures a warm restart, avoiding the index rebuild and its side effects. ::: strong consistency For namespaces with [`strong-consistency`](https://aerospike.com/docs/database/reference/config#namespace__strong-consistency) enabled, perform planned maintenance that involves a host reboot **one node at a time**, using ASMT to back up and restore the primary index on each node. See the [SC planned maintenance procedure](https://aerospike.com/docs/database/manage/cluster/consistency#planned-maintenance) for the full steps, including quiescing nodes before shutdown. ::: ::: tip ASMT backup and restore are I/O-bound. Aerospike recommends using the [`-z` compression option](https://aerospike.com/docs/database/tools/asmt/options) for planned maintenance. Compression reduces backup file sizes by 15–30% and makes them quicker to write. The benefit is most significant when the backup volume has limited throughput, such as cloud-attached block storage like EBS or a NAS. ::: ## Related topics - **Next:** [Install ASMT](https://aerospike.com/docs/database/tools/asmt/install) - [Options for ASMT](https://aerospike.com/docs/database/tools/asmt/options) - [Back up indexes with ASMT](https://aerospike.com/docs/database/tools/asmt/backup) - [Restore indexes with ASMT](https://aerospike.com/docs/database/tools/asmt/restore) - [How to speed up cold start](https://support.aerospike.com/hc/en-us/articles/49939465353115-How-To-Speed-Up-Cold-Start) knowledge base article.