--- title: "ActiveMQ Backup and Disaster Recovery: Complete DR Guide" date: 2026-07-06 author: "TheFrameGuy" featured_image: "https://www.meshiq.com/wp-content/uploads/blog_activeMQ-backup-recovery_07062026.jpg" categories: - name: "Apache ActiveMQ®" url: "/sort-by/active-mq.md" - name: "Devops" url: "/sort-by/devops.md" - name: "Messaging" url: "/sort-by/messaging.md" - name: "Middleware" url: "/sort-by/middleware.md" - name: "Middleware Optimization" url: "/sort-by/middleware-optimization.md" - name: "Monitoring" url: "/sort-by/monitoring.md" - name: "MQ" url: "/sort-by/mq.md" - name: "Observability" url: "/sort-by/observability.md" - name: "SaaS" url: "/sort-by/saas.md" tags: - name: "devops" url: "/sort-by/tag/devops.md" - name: "middleware" url: "/sort-by/tag/middleware.md" - name: "monitoring" url: "/sort-by/tag/monitoring.md" - name: "Observability" url: "/sort-by/tag/observability.md" --- # ActiveMQ Backup and Disaster Recovery: Complete DR Guide Unlike stateless services, ActiveMQ holds your unprocessed business messages: every order not yet confirmed, every transaction not yet committed, every notification not yet delivered. Losing that data is not just a technical incident; it is a business incident. This guide covers ActiveMQ backup and disaster recovery across the full spectrum: what must be backed up and why, backup procedures for KahaDB and the Apache Artemis™ journal, how to recover from KahaDB corruption with and without a backup, Artemis’s native point-in-time recovery via journal-retention-directory, the RTO/RPO framework for messaging infrastructure, and cross-datacenter DR architecture patterns. ## What Must Be Backed Up A complete ActiveMQ backup comprises four distinct categories. Missing any one of them makes your backup & disaster recovery posture incomplete for a full system recovery. ### 1. Configuration Files **Apache ActiveMQ®:** conf/activemq.xml, conf/login.config, conf/credentials.properties, conf/log4j2.properties, any custom policy files. **Apache Artemis™:** etc/broker.xml, etc/artemis.profile, etc/bootstrap.xml, etc/logging.properties, etc/login.config. Configuration files should live in version control (Git), independent of any other backup mechanism. Every configuration change is a deployable artifact. If the broker data directory is lost but the configuration is in Git, rebuilding the broker is a known, repeatable operation. ### 2. Message Store **Apache ActiveMQ® (KahaDB):** The complete data/kahadb/ directory. This contains: - db-N.log – journal files (append-only message log, one or more files) - db.data – the B-tree index mapping message IDs to journal positions - db.redo – the redo log for in-progress index writes (crash recovery) - db.free – free space tracking **The consistency requirement:** All KahaDB files must be from the same consistent point in time. An inconsistent ActiveMQ backup, for example, journal files from time T and a db.data index from time T+1, cannot be restored. The index would reference journal positions that don’t exist in the backed-up journal files, causing startup failure or silent message loss. **Apache Artemis™:** The instance data directory containing: - data/journal/ – activemq-data-N.amq journal files (primary message store) - data/bindings/ – activemq-bindings.amq (address and queue metadata) - data/paging/ – paged messages (present when addresses exceed max-size-bytes) - data/large-messages/ – large message body files stored outside the journal ### 3. Credentials and Security Material Keystore and truststore files for TLS, JAAS credential properties, and any external security integration configurations. These are often overlooked in backup procedures and become the blocking dependency in disaster recovery restoration. You can restore all message data, but you will be unable to start the broker because the keystore is missing. ### 4. Custom JARs and Plugins Any custom interceptors, destination policies, authentication plugins, or monitoring agents deployed to lib/. These are rarely version-controlled but are required for a running broker. ## ActiveMQ Backup Procedures: Stopped vs. Live Broker ### Option 1: Stopped Broker Backup (Highest Consistency) The simplest and most reliable ActiveMQ backup strategy: stop the broker cleanly, copy the data directory, restart. bash \#!/bin/bash \# Classic stopped-broker backup script ACTIVEMQ\_HOME=/opt/activemq BACKUP\_DIR=/backup/activemq/$(date +%Y%m%d-%H%M%S) mkdir -p “$BACKUP\_DIR” \# Step 1: Graceful broker stop (waits for in-flight operations to complete) “$ACTIVEMQ\_HOME/bin/activemq” stop sleep 5 \# Step 2: Verify broker is stopped if pgrep -f activemq > /dev/null; then echo “ERROR: Broker still running. Aborting backup.” exit 1 fi \# Step 3: Copy complete KahaDB directory cp -a “$ACTIVEMQ\_HOME/data/kahadb/” “$BACKUP\_DIR/kahadb/” \# Step 4: Copy configuration cp -a “$ACTIVEMQ\_HOME/conf/” “$BACKUP\_DIR/conf/” \# Step 5: Compress (optional — trades space for transfer speed) tar -czf “${BACKUP\_DIR}.tar.gz” -C “$(dirname $BACKUP\_DIR)” “$(basename $BACKUP\_DIR)” rm -rf “$BACKUP\_DIR” \# Step 6: Restart broker “$ACTIVEMQ\_HOME/bin/activemq” start echo “Backup completed: ${BACKUP\_DIR}.tar.gz” echo “Backup size: $(du -sh “${BACKUP\_DIR}.tar.gz” | cut -f1)” **Downtime cost:** Typically 30-60 seconds for a clean stop/start cycle with a small KahaDB. For large KahaDB stores (millions of persistent messages), journal replay on restart may take minutes. Schedule this during a maintenance window. ### Option 2: Live Filesystem Snapshot (Minimal Downtime) On Linux with LVM, ZFS, or a cloud storage volume, a filesystem snapshot creates a consistent point-in-time copy without stopping the broker. The snapshot must be created atomically, not a sequential file copy. bash \# LVM snapshot backup (Linux) \# Assumes KahaDB is on /dev/vg0/activemq-data, mounted at /opt/activemq/data SNAP\_SIZE=5G TIMESTAMP=$(date +%Y%m%d-%H%M%S) SNAP\_NAME=”activemq-snap-$TIMESTAMP” lvcreate -L “$SNAP\_SIZE” -s -n “$SNAP\_NAME” /dev/vg0/activemq-data mkdir -p /mnt/activemq-snap mount -o ro /dev/vg0/”$SNAP\_NAME” /mnt/activemq-snap rsync -a /mnt/activemq-snap/kahadb/ /backup/activemq/”$TIMESTAMP”/kahadb/ umount /mnt/activemq-snap lvremove -f /dev/vg0/”$SNAP\_NAME” **On Kubernetes:** Use PVC volume snapshots (CSI VolumeSnapshot API) to create consistent point-in-time copies of the broker’s PersistentVolumeClaim without stopping the broker pod: yaml apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: activemq-data-snapshot-2026-04-04 namespace: messaging spec: volumeSnapshotClassName: csi-gce-pd-vsc source: persistentVolumeClaimName: data-activemq-0 We covered the complete Kubernetes StatefulSet and PVC configuration in our [ActiveMQ on Kubernetes](https://www.meshiq.com/blog/activemq-kubernetes-deployment/) post. ### Option 3: JDBC Persistence: Database Native Backup If you’re using JDBC persistence (Apache ActiveMQ® or Apache Artemis™), the message store lives in a relational database. Back up ActiveMQ data using the database’s native backup tools: bash \# PostgreSQL pg\_dump -Fc -h localhost -U activemq activemq\_db > activemq\_db\_$(date +%Y%m%d).dump \# MySQL/MariaDB mysqldump –single-transaction activemq\_db > activemq\_db\_$(date +%Y%m%d).sql –single-transaction (MySQL) and -Fc (PostgreSQL) ensure consistent snapshots without table locks. JDBC persistence backups are simpler to make consistent than KahaDB file backups because the database handles transaction isolation. ## Apache Artemis™ Journal Retention: Native Point-in-Time Recovery Apache Artemis™ provides a native backup & disaster recovery capability that Apache ActiveMQ® lacks: journal-retention-directory. When configured, Artemis automatically copies every journal file it finishes writing before reclaiming it to a separate retention directory. This creates a rolling archive of all messages that ever passed through the broker. xml <!– broker.xml — Artemis journal retention configuration –> <**configuration**> <**core**> <!– Retain 30 days of journal history, up to 50GB –> <**journal-retention-directory** unit=”DAYS” period=”30″ storage-limit=”50G”> history </**journal-retention-directory**> <!– Files are stored in: ARTEMIS\_INSTANCE/data/history/ –> </**core**> </**configuration**> **Recovery using the Apache Artemis™ CLI:** bash \# Recover broker state to a specific point in time (run while broker is STOPPED) \# List available recovery points ./artemis data print –journal ../data/history/ \# Recover all messages from retained journal to a target directory ./artemis data recovery \\ –journal ../data/history \\ –target ../data/recovered \\ –large-messages ../data/large-messages \# Copy recovered journal and restart cp -a ../data/recovered/journal/\* ../data/journal/ ./artemis run**Storage limits:** The retention directory accumulates journal files until it hits storage-limit. For a 30-day retention with a 50GB limit, plan for approximately 1.7GB of retention storage per day at 10,000 messages/day of 1KB average size. **Point-in-time recovery** is Artemis’s key DR advantage, you can recover to the state just before a specific event (an accidental mass delete, a data corruption event at a known timestamp) rather than just to the latest backup. Combined with standard HA replication for broker-level availability, journal retention provides a complete continuity story for Artemis deployments. ## **Building an Enterprise DR Plan for Your ActiveMQ Deployment?** Designing backup and disaster recovery for a messaging broker requires understanding both the broker’s internals and your organization’s RPO/RTO requirements. meshIQ’s team has designed DR architectures for ActiveMQ in regulated industries, including banking, healthcare, and government environments, where message loss directly translates to business impact. [****Request a DR Architecture Review****](https://www.meshiq.com/apache-activemq/enterprise-support/) ## KahaDB Corruption: Recovery Procedures KahaDB corruption occurs when the broker is interrupted during a journal write. The three most common triggers are disk full (the broker is mid-write when space runs out), abrupt power loss or process kill (kill -9), and NFS/network filesystem disconnect during a write. The result is a partial journal record that the index references but cannot read. ### Recognizing KahaDB Corruption \# Pattern 1: Index corruption (most recoverable) ERROR | Failed to start Apache ActiveMQ. Reason: java.io.IOException: Index corrupted \# Pattern 2: Journal record corruption INFO | Corrupt journal records found in ‘db-326.log’ between offsets: 19460423-21031378 ERROR | Failed to start ActiveMQ JMS Message Broker. Reason: java.io.EOFException \# Pattern 3: Journal-index inconsistency ERROR | Failed to load message at: 67459:30059414 java.io.IOException: Unexpected error on journal read### Recovery Procedure 1: Index-Only Corruption (No Message Loss) When journal files are intact but the index (db.data) is corrupted, the index can be rebuilt from the journal with zero message loss: bash \# Step 1: Stop the broker /opt/activemq/bin/activemq stop \# Step 2: Backup the corrupted kahadb for forensics cp -a /opt/activemq/data/kahadb /opt/activemq/data/kahadb\_corrupted\_$(date +%Y%m%d) \# Step 3: Delete ONLY the index files (journal files are preserved) rm /opt/activemq/data/kahadb/db.data rm /opt/activemq/data/kahadb/db.redo \# Step 4: Restart — broker replays journal files to rebuild the index /opt/activemq/bin/activemq start \# Step 5: Monitor startup log for index rebuild tail -f /opt/activemq/data/activemq.log | grep -E “Recovering|Recovery replayed|Journal” \# Expected: \# INFO | Recovering from the journal @0:0 \# INFO | Recovery replayed 45231 operations from the journal in 127.3 seconds. **Index rebuild time:** Proportional to the number of journal records (not messages). For a KahaDB with 1 million persistent messages, expect 2-10 minutes. The broker is unavailable during this period. ### Recovery Procedure 2: Journal Corruption (Selective Message Loss) When specific journal records are corrupt but the index and remaining journal files are intact: xml <!– activemq.xml — enable corruption recovery mode before restart –> <**persistenceAdapter**> <**kahaDB** directory=”${activemq.data}/kahadb” checkForCorruptJournalFiles=”true” checksumJournalFiles=”true” ignoreMissingJournalfiles=”true”/> </**persistenceAdapter**> bash /opt/activemq/bin/activemq start \# Expected output: \# INFO | Corrupt journal records found in ‘db-326.log’ between offsets: 19460423-21031378 \# INFO | Detected missing/corrupt journal files. Dropped 5 messages from the index in 0.003 seconds. \# INFO | Apache ActiveMQ started successfully **Accepted message loss:** The messages in corrupt journal records are dropped, typically the most recently produced messages, a small, bounded loss consistent with the “at-least-once” delivery guarantee. **Important:** ignoreMissingJournalfiles=true with checkForCorruptJournalFiles=false will silently skip corrupted records. Always set checkForCorruptJournalFiles=true simultaneously so corruption events are visible in the log. ### Recovery Procedure 3: Complete KahaDB Loss (Restore from Backup) bash \# Step 1: Stop broker /opt/activemq/bin/activemq stop \# Step 2: Move (don’t delete) the corrupted KahaDB mv /opt/activemq/data/kahadb /opt/activemq/data/kahadb\_LOST\_$(date +%Y%m%d) \# Step 3: Restore from the most recent consistent backup tar -xzf /backup/activemq/20260403-020000.tar.gz \\ -C /opt/activemq/data/ \\ –strip-components=1 \\ “\*/kahadb/” \# Step 4: Verify the restored directory ls /opt/activemq/data/kahadb/ \# Expected: db.data, db.redo, db-N.log files \# Step 5: Restart /opt/activemq/bin/activemq start **Message loss from restoration:** All messages produced since the backup’s timestamp are not in the restored KahaDB. The RPO is the age of the backup. If the backup is from 2 AM and corruption occurred at 3 PM, 13 hours of persistent messages are lost. ## KahaDB Hardening: Prevention Before Recovery The best disaster recovery is the one you never need. These KahaDB configuration settings harden the store against corruption: xml <**persistenceAdapter**> <**kahaDB** directory=”${activemq.data}/kahadb” checksumJournalFiles=”true” checkForCorruptJournalFiles=”true” enableJournalDiskSyncs=”true” journalMaxFileLength=”33554432″ archiveCorruptedIndex=”true” /> </**persistenceAdapter**>checksumJournalFiles=true is the single most important hardening setting. It enables ActiveMQ to detect corruption proactively rather than discovering it as a broker startup failure or a silent message read error. The checksum overhead on journal reads is minimal, typically <1%, and is the only way to distinguish valid journal data from hardware-induced bit flips. We covered the journal architecture, file roles, and enableJournalDiskSyncs trade-offs in depth in our [Message Persistence Strategies](https://www.meshiq.com/blog/activemq-message-persistence-strategies/) post. ## High Availability vs. Disaster Recovery: Understanding the Boundary A common misconception is that an ActiveMQ HA configuration is also a DR configuration. When it comes to high availability vs disaster recovery, they are not the same, and confusing them creates a dangerous gap in your continuity plan. **Property****HA (High Availability)****DR (Disaster Recovery)****Scope**Single broker/node failureDatacenter or site failure**Mechanism**Shared-store or replication ha-policyOff-site backup or cross-DC replication**Failover trigger**Automatic (broker death detected)Manual or semi-automated**RTO**Seconds to <1 minuteMinutes to hours**RPO**Near-zero (persistent messages)Equal to backup frequency**Non-persistent messages**Lost on failureLost on failure (always)**Apache ActiveMQ® mechanism**Master/Slave, JDBC HA, Network of BrokersFile backup + cross-DC NoB**Apache Artemis™ mechanism**shared-store, replication ha-policyjournal-retention-directory + cross-DC**Protects against**“The broker crashed”“The datacenter is gone”We covered the Apache ActiveMQ® and Apache Artemis™ HA architecture options: shared-store, JDBC Master/Slave, Artemis live-backup replication in our [High Availability Architecture Guide](https://www.meshiq.com/blog/activemq-high-availability-architecture/) post. **The key design principle:** HA provides broker-level resilience. DR provides site-level resilience. Both are required for enterprise-grade messaging infrastructure. ### What Fails Over and What Doesn’t Even with a perfect HA configuration, ActiveMQ makes explicit guarantees about what survives failover: **Survives failover (persistent messages only):** - Persistent messages in queues are not yet acknowledged - Durable topic subscriptions and their pending messages - Transaction state for transactions committed before the failure **Lost on any failover (by design, not a bug):** - Non-persistent messages (always in-memory only) - In-flight messages during the failover window (sent but not committed) - Active JMS sessions (must be re-established by clients) - Message acknowledgments in progress at the time of failure The Artemis documentation is explicit: the new session recreated on the backup will have no knowledge of messages already sent or acknowledged in that session. Client-side duplicate detection (duplicate-id header) and transaction retry are the mechanisms for an exactly-once delivery guarantee across failover. ## RTO/RPO Framework for ActiveMQ Backup and Disaster Recovery Defining Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets before choosing a backup strategy is the correct order of operations. The targets determine the architecture, not the other way around. ### RPO Targets and Mechanisms **RPO Target****Required Mechanism****0 (zero message loss)**Synchronous block-level disk replication (DRBD, Ceph) between sites. Every write is committed to the DR site before acknowledging to the client.**Seconds**Apache Artemis™ journal retention with frequent archiving, or synchronous HA replication + separate async DR site.**Minutes**Hourly filesystem snapshots or JDBC database backup with –single-transaction. Acceptable for most enterprise workflows.**Hours**Daily backup archive. Appropriate for lower-criticality queues where some message loss is acceptable. ### RTO Targets and Mechanisms **RTO Target****Required Mechanism****< 1 minute**Hot standby: HA is active, failover is automated. The DR site is continuously synchronized. Promotion is scripted.**< 10 minutes**Warm standby: broker running at DR site in passive mode. Promotion requires a manual or scripted journal replay from the retention directory.**< 1 hour**Cold standby: broker not running at DR site. Restore from backup, start broker, journal replay on startup. RTO depends on the KahaDB index rebuild time for large stores.**> 1 hour**Cold backup only: acceptable only for non-critical messaging workloads where the business process can tolerate extended downtime. ## Cross-Datacenter Backup & Disaster Recovery Architecture Patterns ### Pattern 1: Block-Level Disk Replication (Zero RPO) Synchronous block-level disk replication (DRBD for Linux, Ceph, or cloud storage replication between regions) replicates every byte written to the primary KahaDB or Artemis journal to the DR site synchronously before the write is acknowledged to the broker. From the broker’s perspective, writing to the local disk makes the replication transparent. **Trade-off:** The write latency for every persistent message includes the cross-datacenter round-trip. For a DC pair with 10ms inter-site latency, synchronous replication adds ~10ms to every persistent message send. For throughput-critical deployments, this cost must be benchmarked against the RPO requirement. **Failover procedure:** 1. DR site detects primary site outage (via health check or manual) 2. Promote the replicated volume on the DR site to writable 3. Start the ActiveMQ broker on the DR site, pointing to the promoted volume 4. Update DNS/load balancer to redirect clients to DR site ### Pattern 2: Network of Brokers Cross-DC (Async, Near-Zero RPO) For Apache ActiveMQ® deployments, a Network of Brokers bridge between the primary and DR datacenter provides async message replication. Messages sent to the primary broker are forwarded to the DR broker via a networkConnector. With appropriate durable subscriptions and persistent forwarding, this achieves near-zero RPO for messages that have been forwarded before a primary site failure. xml <!– Primary DC broker: activemq.xml — forward to DR DC –> <**networkConnectors**> <**networkConnector** name=”primary-to-dr” uri=”static:(tcp://dr-broker.datacenter2.internal:61616)” duplex=”false” messageTTL=”-1″ consumerTTL=”1″ userName=”${dr.broker.user}” password=”${dr.broker.password}”/> </**networkConnectors**>**Limitation:** Messages in the primary broker’s queue that have not yet been forwarded to the DR broker before the site failure are lost. The RPO is the forwarding latency, typically seconds to minutes, depending on consumer activity at the DR site. We covered Network of Brokers configuration, TTL settings, and topology patterns in our [Network of Brokers Configuration ](https://www.meshiq.com/blog/activemq-network-of-brokers-configuration/) post. ### Pattern 3: Apache Artemis™ Diverts + Core Bridge (Async, Selective DR) For Artemis, diverts and core bridges provide selective message mirroring between sites. A divert copies or moves matching messages from a source address to a target address; a core bridge forwards messages across a network connection to the DR site broker. xml <!– broker.xml — Artemis divert to mirror critical queues to DR –> <**divert** name=”orders-dr-divert”> <**address**>orders</**address**> <**forwarding-address**>orders.dr</**forwarding-address**> <**exclusive**>false</**exclusive**> </**divert**> <!– Core bridge: forward orders.dr to the DR site broker –> <**bridge** name=”orders-dr-bridge”> <**queue-name**>orders.dr</**queue-name**> <**forwarding-address**>orders</**forwarding-address**> <**static-connectors**> <**connector-ref**>dr-site-connector</**connector-ref**> </**static-connectors**> <**ha**>true</**ha**> <**reconnect-attempts**>-1</**reconnect-attempts**> </**bridge**>**Advantage over Apache ActiveMQ® NoB:** Artemis diverts are configurable per address, enabling selective replication of only critical queues to the DR site, rather than all destinations. This reduces DR infrastructure costs and cross-DC bandwidth costs. ## **Monitor Backup Status and DR Readiness Across Your ActiveMQ Fleet** meshIQ Console tracks broker health metrics: journal size growth, disk utilization, replication lag for Apache Artemis™ backup brokers, and KahaDB checkpoint age, giving you continuous visibility into whether your DR posture matches your SLA commitments. [****See It in Action****](https://www.meshiq.com/request-a-demo/) ## Backup and Disaster Recovery Checklist **ActiveMQ Backup Configuration:** - Configuration files (activemq.xml / broker.xml) in version control - Backup schedule defined: stopped-broker (daily minimum) or live snapshot - Backup verification tested: restored backup starts broker successfully - Backup retention policy defined and implemented (e.g., 7 daily, 4 weekly, 12 monthly) - Backup storage is off-host (not on the same disk as KahaDB) - checksumJournalFiles=true and checkForCorruptJournalFiles=true enabled in production **Apache Artemis™-Specific:** - journal-retention-directory configured with period and storage-limit - artemis data recovery CLI tested in pre-production environment - Retention storage monitored as a separate alert threshold **DR Architecture:** - RPO and RTO targets are formally defined for each message tier - DR architecture matches RPO/RTO targets (not just “we have backups”) - DR site can receive broker traffic (DNS/load balancer tested in DR mode) - Failover procedure documented and rehearsed (not just written) - Client failover transport configured: failover:(primary:61616,dr:61616) **Testing:** - Backup restore test performed in pre-production (at least quarterly) - DR failover drill performed (at least annually) - KahaDB index rebuild time measured with production-scale data volume ## Backup Is the Contract You Make Before the Incident The quality of an ActiveMQ backup and disaster recovery plan is not measured by how comprehensive the documentation is, it is measured by the last time the restore procedure was tested under conditions that resembled a real failure. KahaDB corruption scenarios, large-store index rebuild times, and failover client reconnection behavior all produce surprises in production that only testing reveals. Build the backup procedure. Test the restore. Measure the KahaDB index rebuild time for your data volume. Document the actual RTO you observed, not the theoretical one. The difference between these numbers is the gap in your DR plan. We’ll cover log analysis and diagnostics in the next post in this series, including how to use ActiveMQ logs to detect early signs of corruption before it becomes unrecoverable. **Get your ActiveMQ DR plan reviewed by our team → [Request a DR Architecture Review](https://www.meshiq.com/apache-activemq/enterprise-support/)** --- ### **Frequently Asked Questions** **Q: How do I back up ActiveMQ?** Back up three things: configuration files (activemq.xml / broker.xml) in version control; the complete message store (data/kahadb/ for Apache ActiveMQ®, data/journal/ + data/bindings/ for Apache Artemis™) as a consistent snapshot; and any security material (keystores, login.config). Never back up only part of the KahaDB directory, inconsistent backups cannot be restored. **Q: How do I recover from KahaDB corruption?** If only the index is corrupted (journal intact): delete db.data and db.redo, restart the broker rebuilds the index from journal replay. If journal records are corrupt: enable checkForCorruptJournalFiles=true and ignoreMissingJournalfiles=true and restart, the broker skips corrupt records with bounded message loss. If all data is lost, restore from backup. **Q: What is the difference between high availability and disaster recovery for ActiveMQ?** HA protects against single-broker failures within a datacenter (automated, seconds RTO). DR protects against site-level failures (manual/scripted, minutes-to-hours RTO). When evaluating high availability vs disaster recovery, the key distinction is failure scope, HA does not replace DR, and both are required for enterprise messaging infrastructure. **Q: Does ActiveMQ Apache Artemis™ have a built-in backup feature?** Yes, journal-retention-directory in broker.xml automatically archives journal files for a configured retention period. The artemis data recovery CLI can replay retained journal files to reconstruct broker state at any past point in time, enabling point-in-time recovery without external backup tooling. **Q: What RTO and RPO can ActiveMQ achieve?** Hot standby with HA: RTO <1 minute, RPO near-zero for persistent messages. Warm standby with periodic snapshots: RTO 10–30 minutes, RPO = snapshot frequency. Cold standby with file backup: RTO 30 minutes to hours, depending on KahaDB index rebuild time. Non-persistent messages always carry RPO=0 (lost on any failure) regardless of DR tier.