Documentation update request: Backups

[darth-drew]

Discussion References: #1558, #3444
Issue References: #1561

Personally, I am getting very close to deploying to OPs, but am hoping for a documentation update on backup best practices. From what I gather, in the case of a critical manager failure, a new manager can be made to work assuming it has the same name/IP, but you will at least need current backups of the following:
/opt/so/saltstack
/etc/salt
/etc/pki
..also ES data for any custom Kibana dashboards.

More recent guidance: Configuration backups are stored in /nsm/backups (daily, woot!).

Assuming the more recent guidance of using /nsm/backups covers the previous, what would that recovery procedure look like? Are those backups considered relatively comprehensive, or are there other directories that should be backed as well?

I appreciate any input. Obviously snapshotting entire VMs can get very expensive.

Thanks again to all you guys! My customer is very excited for all SO is going to bring to the table. There are countless improvements over what they currently have.

[facyber]

Hi @darth-drew,

Thanks for the tips (and of courses to SO devs). I also started working on some type of backup procedure, or better say retention policy. My initial idea was keeping ES data and PCAPs for two weeks, then archiving them and store them on external mounted storage, and keep them there for a few weeks more (1 month retention data policy sort of).

How do you manage to backup ES data? for the moment I am working on creating Curator script (will share it soon as it is completed and tested) that will backup only specific indices for a start and low level of data.

Cheers!

[weslambert]

Many folks utilize Curator snapshotting for backing up ES data -- whether that is to a share, S3, etc.