Backup / Restore

This page covers backup and restore of an Atomic OSSEC (AEO) hub: OSSEC manager state under /var/ossec and AWP hub state under /var/awp.

For NFS-based persistent storage layouts, see Site Reliability Engineering (SRE).

In a clustered deployment, back up the master hub. Workers re-synchronize agent keys and shared configuration from the master. See Clustering.

What to back up

Critical persistent data on the hub:

Path

Purpose

/var/ossec/etc/

Manager configuration, agent keys (client.keys), shared agent policies (shared/), local rules (rules.d/), and auth material

/var/ossec/queue/

FIM and agent database state (including queue/db/)

/var/ossec/logs/

Alerts, archives, and related manager logs

/var/ossec/ac-cluster/etc/.comms.key

Cluster communications key (required when clustering is enabled)

/var/ossec/.ssh/

Agentless SSH keys (when agentless monitoring is used)

/var/awp/etc/

Hub configuration, SSL certificates (.ssl/ / ssl/), per-group policy JSON under agents/

/var/awp/data/

Console users and groups (.awp.dat, .awp.key), reports, vulnerability/SCA data, quarantine, and related hub service data

Note

/var/awp/www/ is normally provided by packages and is not first-class backup state. Prefer restoring packages, then overlaying /var/awp/etc and /var/awp/data.

Backup procedure

Step 1: Quiesce services

Stop the manager and hub services so the snapshot is consistent:

systemctl stop awpd
systemctl stop ossec-hids

Step 2: Archive OSSEC manager state

Example (tar to a mounted volume):

mkdir -p /mnt/hub-backup
tar -czf /mnt/hub-backup/ossec-etc-$(date +%Y%m%d).tar.gz -C / var/ossec/etc
tar -czf /mnt/hub-backup/ossec-queue-$(date +%Y%m%d).tar.gz -C / var/ossec/queue
tar -czf /mnt/hub-backup/ossec-logs-$(date +%Y%m%d).tar.gz -C / var/ossec/logs

If clustering is enabled, also archive the cluster key directory:

tar -czf /mnt/hub-backup/ossec-ac-cluster-$(date +%Y%m%d).tar.gz \
  -C / var/ossec/ac-cluster/etc

Example (rsync over SSH):

rsync -av -e ssh root@aeo:/var/ossec/etc/ /mnt/hub-backup/ossec-etc/
rsync -av -e ssh root@aeo:/var/ossec/queue/ /mnt/hub-backup/ossec-queue/
rsync -av -e ssh root@aeo:/var/ossec/logs/ /mnt/hub-backup/ossec-logs/

Step 3: Archive AWP hub state

tar -czf /mnt/hub-backup/awp-etc-$(date +%Y%m%d).tar.gz -C / var/awp/etc
tar -czf /mnt/hub-backup/awp-data-$(date +%Y%m%d).tar.gz -C / var/awp/data

Or with rsync:

rsync -av -e ssh root@aeo:/var/awp/etc/ /mnt/hub-backup/awp-etc/
rsync -av -e ssh root@aeo:/var/awp/data/ /mnt/hub-backup/awp-data/

Step 4: Restart services

systemctl start ossec-hids
systemctl start awpd

Restore procedure

Restore configuration and identity first, then queue and log data.

Step 1: Stop services

systemctl stop awpd
systemctl stop ossec-hids

Step 2: Restore archives

Extract on the target hub (paths assume archives created as above):

tar -xzf /mnt/hub-backup/ossec-etc-YYYYMMDD.tar.gz -C /
tar -xzf /mnt/hub-backup/awp-etc-YYYYMMDD.tar.gz -C /
tar -xzf /mnt/hub-backup/awp-data-YYYYMMDD.tar.gz -C /
tar -xzf /mnt/hub-backup/ossec-queue-YYYYMMDD.tar.gz -C /
tar -xzf /mnt/hub-backup/ossec-logs-YYYYMMDD.tar.gz -C /

If clustering was in use:

tar -xzf /mnt/hub-backup/ossec-ac-cluster-YYYYMMDD.tar.gz -C /

Step 3: Fix ownership and modes

Align with the usual hub layout (see also Site Reliability Engineering (SRE)):

chown -R root:ossec /var/ossec/etc
chmod 770 /var/ossec/etc
chown -R ossec:ossec /var/ossec/logs
chmod 750 /var/ossec/logs
chown -R root:ossec /var/ossec/queue
chmod 550 /var/ossec/queue

Preserve ownership from the backup when possible (tar / rsync -a). Adjust only if ownership was lost during transfer.

Step 4: Start services and verify

systemctl start ossec-hids
systemctl start awpd

Confirm:

  • Hub console login works (depends on /var/awp/data/.awp.dat and .awp.key)

  • Agents reconnect (/var/ossec/etc/client.keys and shared policies restored)

  • If clustered, /var/ossec/ac-cluster/etc/.comms.key matches across nodes

Backup: Alert data (Cold Storage)

Alert data is rotated and compressed in JSON and log format every 24 hours. AEO indexes the JSON data in the console; these archives are the primary focus for long-term alert retention backups.

Step 1: Backup / transfer archive data

Copy /var/ossec/logs/alerts/<YYYY>/<Mon>/ to the backup location.

Example (rsync over SSH):

rsync -av -e ssh root@aeo:/var/ossec/logs/alerts/2020/* /mnt/hub-backup/alerts/

Restore: Alert data (Cold Storage)

Step 1: Transfer cold storage to hot storage

Copy backup data to /var/ossec/logs/alerts/<YYYY>/<Mon>/.

Example (rsync over SSH):

rsync -av -e ssh /mnt/hub-backup/alerts/ root@aeo:/var/ossec/logs/alerts/2020/

Step 2: Re-index restored data

On the AEO hub run:

systemctl stop awpd

/var/awp/bin/awp_indexgen

systemctl start awpd

Note

Index generation can take several minutes per file.

Search / OpenSearch recovery

There is no separate OpenSearch volume snapshot procedure in this guide. To recover searchable alert history:

  1. Restore alert archives under /var/ossec/logs/alerts/ (see cold storage above).

  2. Run /var/awp/bin/awp_indexgen after stopping awpd, then start awpd again.

Optional components

Agentless SSH keys

If you use agentless monitoring, include /var/ossec/.ssh/ (and any registered agentless host state under /var/ossec/agentless/) in the backup set with the OSSEC manager archives.

MySQL / database output

If OSSEC database output is enabled on the hub, back up that database with your normal database tools in addition to the filesystem trees above. Most hubs do not require a separate MySQL dump for day-to-day AEO operation.