Hey folks! We're exploring LogRhythm for SIEM and I'm thinking about it from a GitOps angle. The platform config (rules, dashboards, etc.) stored in its database seems like a critical piece of infrastructure-as-code.
What's the recommended way to back up *just* the configuration database? I'm looking for something scriptable that we can version control and maybe even tie into our existing CI/CD for drift detection. The goal is to have a repeatable recovery process.
I've seen references to `lr-admin-db-backup` but I'm curious about practical details:
- Do you dump the whole DB or just specific tables?
- How do you handle encryption/secrets management for the backup file?
- Any clever tricks with `mysqldump` or similar?
```bash
# Something like this?
lr-admin-db-backup -f /backup/lr_config_backup.sql
```
> git commit -m 'done'
git push and pray
I'm a security engineer at a mid-sized financial services company, and we've run LogRhythm in production for about three years, managing all our alert rules, dashboards, and case management through its SQL backend.
1. **Scope of Backup:** You need the `lr_config_db` database specifically. Using `mysqldump` on the whole instance includes operational data like alarms and case history that you likely don't want in version control. The command `lr-admin-db-backup` does this by default, but you can replicate it with `mysqldump -u [user] -p lr_config_db > backup.sql`.
2. **Secrets Handling:** The backup will contain encrypted credentials, but the encryption keys are in the file. You must encrypt the backup file itself post-dump. We use `gpg` with a CI/CD-managed key pair and immediately shred the unencrypted temp file.
```bash
gpg --symmetric --cipher-algo AES256 --output /backup/lr_config_backup.sql.gpg /backup/lr_config_backup.sql
rm /backup/lr_config_backup.sql
```
3. **Drift Detection Method:** A full dump is too noisy for Git diffing. We extract just the rule definitions (`lr_rule` table) and dashboard JSON (`lr_dashboard` table) into separate, formatted JSON files using a Python script. That's what we commit. The full encrypted dump is stored separately in object storage for recovery.
4. **Recoverability Gotcha:** Restoring a configuration backup requires the same LogRhythm software version. A backup from version 7.8.1 might fail on 7.7.5 due to schema changes. We pin the backup script to check the version and store it as metadata.
My pick is a hybrid approach: scripted `mysqldump` of `lr_config_db` for recovery, plus selective table exports to Git for diffing. If your team is small, just use and encrypt `lr-admin-db-backup`. To choose cleanly, tell us your LogRhythm version spread across deployments and whether you need to audit configuration changes per SOC 2.
patch early
Skip the official tool if you need version control. Use `mysqldump` with `--skip-extended-insert` to get one-row-per-line output, which makes diffs in git actually readable. It's a pain to review a SQL file where every table is a single line.
Don't version the raw dump though. The credential tables are a liability. We pipe the dump through a simple Python script that redacts specific table columns before committing. The script keeps the structure but replaces sensitive values with a placeholder. That way your drift detection works on the config logic, not the encrypted noise.
Observability is not monitoring
I love the GitOps angle. We're a small shop, so I had to build a similar process without heavy tooling.
The one-row-per-line mysqldump trick mentioned below is a lifesaver for readable diffs. But we found we only needed a subset of tables for true "config as code." We script a dump of just `dashboard`, `report`, `alarm` rule tables, etc., skipping credential and licensing tables entirely. It's cleaner and safer for version control.
For secrets, we don't even back them up in the config stream. We keep them in a separate, encrypted vault. The config SQL references them by IDs that exist in both systems. This way, the git history is purely logic changes you'd actually want to track.
Build with what you have
You're right on the edge of a solid GitOps workflow for SIEM config. Since you're scripting this for CI/CD and drift detection, let me add one practical nuance from our setup.
Your snippet using `lr-admin-db-backup` is fine, but for true version control, you'll want to isolate the schema from the data. We run two separate dumps: one for the schema only (`--no-data`) committed to git, and another for the data (with redaction) stored in a separate, encrypted artifact. This way, structural changes to tables (like a new column for a rule type) are clearly visible in git history, separate from the row-level config changes.
Also, consider the restore path. Your backup script should generate a checksum of the dump file and store it alongside the SQL. That checksum can be committed, giving your CI a quick way to detect if the actual backup artifact has changed without needing to parse the whole SQL file for every pipeline run.
yaml is my native language