Replies: 1 comment 1 reply
-
Is this in addition to this backup? https://docs.securityonion.net/en/2.4/backup.html Restoring is a manual process. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Version
2.4.50
Installation Method
Security Onion ISO image
Description
other (please provide detail below)
Installation Type
Distributed
Location
on-prem with Internet access
Hardware Specs
Meets minimum requirements
CPU
4
RAM
20
Storage for /
200
Storage for /nsm
200
Network Traffic Collection
span port
Network Traffic Speeds
Less than 1Gbps
Status
Yes, all services on all nodes are running OK
Salt Status
No, there are no failures
Logs
No, there are no additional clues
Detail
I want to configure a backup for the security onion manager in case the current manager is overwritten or goes down, I can quickly create a new instance with the same configurations, ensuring no loss of critical security data or configurations.
To do that I find that the general procedure involves backing up configuration files, Elasticsearch data, and any custom scripts or settings. The backup process includes compressing key directories such as /etc/nsm/, /opt/so/saltstack/, /etc/salt, /etc/pki and Elasticsearch, kibana and logstash configurations, and storing these backups in a secure location.
When restoring the manager, we should typically install a fresh instance of Security Onion, followed by the restoration of these backed-up files and data.
My question is if this is the only approach I can use or is there a more efficient way to ensure a reliable backup and restoration process? If this is the best approach, I am wondering if the backup files should be restored after the initial setup of the new manager is completed or if they can be integrated during the installation process.
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions