Graylog backup and restore

What Graylog backup and restore must capture to rebuild a cluster

A backup plan for Graylog has to answer one question: after hardware loss, corruption or a failed upgrade, can the team rebuild the cluster to a working state? That requires capturing two separate data planes. The first is MongoDB, which holds configuration and metadata: inputs, streams, index set definitions, pipeline rules, event definitions, users and roles. The second is the log storage layer, either a Graylog Data Node cluster or a self-managed OpenSearch cluster, which holds the indices themselves. Losing one without the other leaves a rebuilt cluster that either has no configuration to point at its data or has configuration with no logs behind it.

Two more items are easy to forget and break a rebuild just as completely. The server configuration file on each Graylog node carries settings such as the password secret and the connection details for MongoDB and the search backend, so the password secret must be recorded through a secure channel and never stored beside the backup. TLS certificates and their private keys for the web interface, inputs and the search backend must also be recoverable, along with any certificate authority they depend on. Confirm with the Graylog documentation for your running version exactly which files, keys and secrets the product expects, since the current docs cover version 7.2 and older releases differ. Treat that list as the input to your backup scope, and record which system holds each item.

Two decisions follow from this inventory. First, set backup frequency separately for MongoDB and the log store, because configuration changes far less often than indexed log data, and the acceptable loss window for each may differ. Second, define the restore order in advance: the search backend and MongoDB must be available before Graylog nodes start, and the Graylog nodes must match the version that wrote the data. Test that order on a non-production cluster, because a restore that has never been run is an assumption. The exact commands and snapshot procedures depend on your deployment method and version, so confirm them in the Graylog documentation before you write the runbook.

Which backup component covers which data

This table compares the four places Graylog state lives: MongoDB configuration, search storage, server configuration with certificates, and the message journal. Read each row to see what it holds, how to capture it, and whether it can stand in for a backup. The main takeaway is that only the first three support a rebuild, and the journal does not.

Component	What it holds	How it is captured and what it costs to keep	When it fits and what to confirm
MongoDB configuration data	Inputs, streams, pipelines, dashboards, event definitions, users and other metadata that define how the cluster behaves	Captured with MongoDB-level backup tooling on the replica set. Small in size compared with log storage, so retention cost is usually low. Confirm the capture method for your MongoDB version and Graylog release.	Required for any rebuild. Without it, search data exists but nothing routes, parses or displays it. Confirm that backups are taken from a replica set member and include all nodes' roles.
Data Node or OpenSearch snapshots	Indexed log messages and index metadata, which usually make up most of the stored data	Captured as snapshots to a repository the search cluster can reach. Storage cost grows with retention and is often the largest backup cost. Confirm the snapshot repository setup and retention for your Data Node or OpenSearch version.	Needed to recover historical logs and to meet retention evidence needs. Snapshots must be taken on a schedule and kept off the cluster being protected. Confirm restore compatibility across versions.
Server configuration files and certificates	Node settings such as the server configuration file, secrets used for encryption, TLS certificates and keys, and service unit or container definitions	Copied from each node with file-level or configuration management backups. Very small in size, but must be stored encrypted because it contains secrets. Confirm which files your installation method uses.	Needed to bring nodes back with the same identity and trust. Without the original password secret, encrypted data in MongoDB may be unreadable. Keep it separate from log snapshots.
Message journal	Messages accepted by Graylog but not yet written to indices, held on local disk	Not a backup. It is a buffer on each node, sized by ingest rate and disk, and it is lost if the node disk fails. Confirm journal location and size in your configuration.	Useful only for short outages and recovery of in-flight messages. A full or damaged journal can drop uncommitted messages, so it must be monitored rather than relied on.

How the backup approach changes by deployment layout

On a single host, the Graylog server, MongoDB and the search backend usually share one machine, so that host holds everything the cluster needs to come back. Losing the disk loses the configuration, the log indices and the local copies of the keys, so the backup has to pull each of those out of the host on a schedule.

MongoDB configuration data: Streams, pipelines, users, dashboards and event definitions are stored in MongoDB. Dump the database with a method your MongoDB version supports and store the output off the host.
Search backend snapshots: Log indices sit in the Data Node or OpenSearch service on the same machine. Register a snapshot repository on storage outside the host so a disk failure does not remove the snapshots too.
Server configuration: Copy server.conf, including the password secret and the root password settings, and record the exact package version in use.
Certificates and keys: Copy the TLS certificates and private keys used for the web interface and any secured inputs, along with any truststore files.

Check the backup by rebuilding the host from the copied files on a clean machine running the same package version, then confirm that streams, dashboards and a sample search return the expected results.

With Docker Compose, containers can be replaced at any time, so what survives a restart depends on volumes, bind mounts and the files kept beside the compose file. The container images are rebuilt from their sources, but the data and the configuration that make the stack unique must be captured from the host.

Volumes and bind mounts: Identify which named volumes or host paths hold MongoDB data, Graylog data and search backend data. Back up those volumes or paths, not the images.
Compose file and environment: Keep the compose file, the .env file and any override files in version control. Store secret values in a secrets manager rather than in the repository.
Snapshot repository path: If the search backend writes snapshots to a path inside the container, mount that path from the host or from a network share so snapshots survive container replacement.
Certificates mounted into containers: Certificates normally arrive as mounted files. Capture the source files on the host, since the container copy is only a reference to them.

Check the backup by recreating the stack from the saved compose file and restored volumes on a clean host, then confirm that the Graylog web interface lists streams, dashboards and users, and that the search backend reports the restored indices.

The layout Graylog recommends for medium to large deployments spreads state across several hosts: three Graylog and MongoDB nodes running a replica set, three Data Nodes forming their own cluster, and a load balancer in front of the Graylog nodes. Each tier holds part of the state, so the backup has to cover every tier and record how they connect. The multi-node installation guide shows how these pieces are set up.

MongoDB replica set: Take the configuration dump from the replica set using a method your MongoDB version supports for consistent copies, and confirm the members can resume from the restored state.
Data Node snapshots: Register one shared snapshot repository that all three Data Nodes can reach, so a snapshot taken from any node can be restored to the cluster.
Per-host server configuration: Capture server.conf from each Graylog node. Follower nodes set is_leader to false, so the files are not identical and each one must be kept.
Load balancer and names: Record the load balancer configuration, virtual addresses and external host names, because inputs and users depend on them after a rebuild.
Certificates on every host: Collect certificate and key files from the three Graylog nodes, the three Data Nodes and the load balancer.

Check the backup by restoring to a test environment, then confirm that exactly one Graylog node is set as the leader, that followers still carry is_leader set to false, and that every Data Node lists the snapshot repository.

How to set up a Graylog backup routine and a first test restore

This sequence turns Graylog backup from an assumption into a tested routine. You inventory what runs, protect the configuration and search data, schedule the jobs, and prove the cluster can be rebuilt in a separate environment with a written record of what was missing.

Inventory every component and its exact version
Record each Graylog server node, the MongoDB deployment, the Data Node or OpenSearch cluster, the load balancer, and the host operating systems, with exact versions and install method. Check the versions against the Graylog compatibility matrix, because backup tooling and restore targets must match the release you are protecting. Also list the inputs, streams, pipelines, index sets, event definitions and any certificates or secrets in use. The output is a signed-off inventory that the restore test will later be measured against.
Set scope and backup frequency by data criticality
Agree with the data owners which data must be recoverable and how quickly, separating configuration (MongoDB, server config, certificates) from log indices in the search backend. Document the recovery procedure, who approves changes to it, and how backup data is protected, including encryption and separation from the production cluster. Frameworks such as CIS Controls v8.1 Safeguard 11.1 and DORA Article 12(1) expect this written policy. The output is a backup policy with a scope list and a frequency for each data class.
Configure MongoDB backups
Set up scheduled, consistent backups of the MongoDB replica set that holds Graylog configuration and metadata, using the backup method your MongoDB version supports and confirming the operation runs against a secondary where that is appropriate. Store the output off the primary nodes and encrypt it. Your platform team owns this job, and DeployOpen can implement it under a written scope. The output is a recent, restorable MongoDB archive stored in a separate location with a logged completion record.
Register a Data Node or OpenSearch snapshot repository
Create a snapshot repository on storage that is separate from the search cluster, register it with the Data Node or OpenSearch cluster, and create a snapshot policy that matches the frequency agreed in the policy. Confirm the repository is reachable from every data node and that the cluster reports the snapshot as successful. Check the vendor documentation for repository types and permissions in your version, since those details change between releases. The output is a registered repository and a first successful snapshot listed by the cluster.
Protect server configuration and certificates
Copy the Graylog server configuration file, the password and secret settings, and TLS certificates with their private keys into a protected store, such as a secrets manager or encrypted vault with restricted access. Record which values are stored elsewhere, so a rebuild does not depend on a single host. Keep this store separate from the backup target used for MongoDB and snapshots. The output is a versioned, access-controlled copy of every file needed to rebuild a node, with an owner named for each item.
Schedule the jobs and alert on failure
Put the MongoDB backup, snapshot policy and configuration copy on a scheduler, with retention rules that match the policy and alerts when a job fails or runs late. Make sure backup administrator accounts cannot delete backups during their retention period, which the Essential Eight maturity model describes at maturity level 3. Review the schedule with the on-call team so failed jobs are handled. The output is a running schedule with a documented alert route and a list of job owners.
Run a first restore into a separate environment
Build a separate Graylog environment with the same versions from step one, restore MongoDB first, then the search backend from its snapshot, then start the Graylog nodes with the restored server configuration and certificates. Check that the restored cluster shows the expected streams, pipelines, index sets, inputs and event definitions, and that recent messages are searchable within the snapshot window. Record the time each stage took, every missing item, and every manual fix needed. The output is a restore record that lists gaps and assigns fixes before the next test.
Repeat the restore test after changes
Schedule the restore test to repeat on a fixed cadence and after any substantive change, such as a Graylog upgrade, a new index set, or a change to the MongoDB or search topology. DORA Article 11(6) expects recovery plans to be tested at least yearly and after substantive changes for financial entities, which is a useful benchmark for other sectors too. Compare each new restore record with the previous one to confirm gaps are closed. The output is a dated restore history showing the environment was rebuilt successfully and the gaps trend toward zero.

How to protect Graylog backup data and access

A Graylog backup is only useful if it cannot be read, altered or deleted by the wrong people. The cards below cover the controls that protect recovery data at rest and in transit, the separation of duties around it, the secrets that must stay out of plain copies, and the access records you need when a restore happens.

Keep an isolated copy of recovery data

CIS Controls Safeguard 11.4 asks for at least one recovery copy kept isolated from the production environment, such as offline, cloud or off-site storage with version control. For Graylog, that means a copy of the MongoDB dump and the Data Node or OpenSearch snapshots that a compromise of the Graylog network cannot reach. Confirm that the isolated copy is restorable into a clean environment, not only that it exists.

Encrypt and separate recovery data

CIS Controls Safeguard 11.3 asks that recovery data receive the same protection as the original, using encryption or separated storage. Graylog logs often contain personal data, credentials that leaked into messages and security events, so backups need the same classification as the live indices. Decide where the encryption keys live, and keep them apart from the backup files they protect.

Stop backup administrators from deleting copies

Essential Eight maturity level 3 expects that backup administrator accounts cannot modify or delete backups during their retention period. In practice, separate the account that runs backups from the account that can change retention or delete snapshot repositories, and enforce object lock or write-once settings where your storage supports them. Test this by attempting a deletion with the backup operator's credentials.

Keep secrets out of plain backups

Graylog configuration in the server file holds secrets such as the password secret, root password hash and integration credentials, and TLS certificates and private keys sit beside it on the host. Store these in a separate, access-controlled backup with its own retention, not in the same archive as log data. Confirm that a restored server can start with the same password secret, or the stored encrypted values will not decrypt.

Authenticate access to MongoDB and the repository

The MongoDB configuration database and the Data Node or OpenSearch snapshot repository both need authentication, TLS and role restrictions, so a network user cannot dump or overwrite them. Create a dedicated backup user with read-only rights where the tool allows it, and rotate its credentials on a schedule. Check that the repository credentials are not stored in shell history or in world-readable files.

Log every restore and access event

Record who retrieved a backup, who started a restore, and which target system received the data, with timestamps that your central logging keeps separate from Graylog itself. A restore that rewrites configuration or indices is a high-impact change, so keep an audit trail that can be reviewed later. Ask your team to confirm that the logs survive a Graylog outage and that restore approvals are documented.

Restore order and version matching for a Graylog rebuild

A Graylog rebuild only works if the components come back in dependency order. Bring up the MongoDB replica set first, because it holds the configuration and metadata that Graylog server nodes read at startup. Restore the configuration data next, then bring up the Graylog Data Node or self-managed OpenSearch cluster and register the snapshot repository so it can see the backups. Restore index data from snapshots after the search cluster is healthy, then start the Graylog server nodes. Only after the nodes are running should you check that streams, pipelines, inputs and index sets appear as they did before the failure. Starting Graylog before its storage is ready tends to produce a server that looks up but has no searchable data, which makes the failure harder to diagnose.

Every restored component has to sit inside the versions the Graylog compatibility matrix lists for the target Graylog release. Check the MongoDB, Data Node or OpenSearch and Graylog versions in your backup inventory against that matrix before you install anything, and record the exact package versions, not just the major line. Be aware that the matrix also constrains OpenSearch: Graylog Security needs OpenSearch 2.0 or later, and use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. If the rebuild target is a newer release than the one that produced the backup, plan the upgrade as its own step with its own verification, and do not combine it with the restore test without a clear record of which change caused any fault.

Confirm the full sequence against Graylog's restore documentation before you schedule a restore test, because the order above is a general dependency view and the documented steps for your release and package set govern. Ask the vendor or your own runbook owner to confirm which configuration files, MongoDB collections and snapshot settings the documented procedure touches, and whether node IDs, certificates and the is_leader setting on each Graylog node need special handling. Write the confirmed order into the restore runbook with the version pairs it assumes, so the test team can compare the result with the documented expectation rather than with memory of how the system used to work.

What to confirm before relying on these backups

A Graylog backup is only as good as the version match, storage path and restore steps behind it. The cards below list what to verify in the Graylog documentation and in your own environment before you treat a backup set as recoverable.

Documented MongoDB backup method

Confirm in the Graylog documentation for your running version which backup method is documented for MongoDB, since that database holds configuration, users, streams, pipelines and event definitions. Check that the MongoDB version in use falls within the range the compatibility matrix lists for your target Graylog release. A dump taken with a method the documentation does not cover can restore incompletely.

Snapshot repository on your storage

Confirm that the snapshot repository works on the storage you actually use, whether that is a shared filesystem, object storage or a backend supplied by your platform team. Test a write, a list and a read from every Data Node or OpenSearch node that must reach it. Permissions, mount paths and network rules are common reasons a repository looks configured but fails at the first real snapshot.

Search backend versions for the target release

Check the Data Node or self-managed OpenSearch version against the compatibility matrix for the Graylog release you plan to run after a rebuild. Graylog Security needs OpenSearch 2.0 or later. A snapshot taken on one search backend version may only restore onto a compatible version, so confirm the restore target before you upgrade either side.

Deprecated OpenSearch 1.x before Graylog 8.0

Use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. If your clusters still run 1.x, a backup and restore plan that works today may stop being valid at the next major upgrade. Record which backend version each backup was taken from and plan the migration to Data Node or a supported OpenSearch release before that deadline.

Archive restore needs Enterprise

Restoring from the data lake archive is an Enterprise feature that requires an Enterprise license, not part of Graylog Open. Confirm with your Graylog account team or pricing page whether that license applies to your environment before you count archives as part of your recovery design. Snapshots of the search backend remain a separate path that does not depend on this license.

Retention deletes are permanent

Indices removed by retention are not recoverable from snapshots taken afterward, because the snapshot no longer contains them. If you need a longer recovery window than your retention setting, take snapshots at a frequency that captures the data before retention removes it, and confirm that the snapshot schedule and index rotation settings match your recovery target.

Questions teams ask before a Graylog backup and restore project

What drives the cost of a Graylog backup and restore project?

The cost depends mainly on how many components are in scope and how much verification you need. The main components are the MongoDB configuration data, the Data Node or OpenSearch snapshot repository, the Graylog server configuration and certificates, and the restore runbook. Each one needs its own backup design, access setup and test. Cost also rises with the number of Graylog and Data Node nodes, the storage platform used for snapshots, and whether you want a restore rehearsal into a separate environment. DeployOpen scopes the work in writing before any work begins, so you receive a fixed set of deliverables and a quote that follows from that scope. Ask any provider to itemize the components, the test scope and whether ongoing testing is included or quoted separately.

How long does a Graylog backup and restore project take?

The duration depends on the factors that set how much work each component needs. Node count and cluster layout matter because each MongoDB and Data Node member must be captured and restored in a defined order. Data volume and storage throughput matter because snapshot and restore times scale with how much index data moves and how fast the repository can serve it. Test scope matters most for schedule: a single documented restore takes less time than repeated restores into a clean rebuild with timed results. Your change windows and the availability of your staff also shape the calendar. Agree the timeline in the written scope, and ask for the assumptions behind it, including the data volume and repository type they assumed.

What does the work need from our team?

The work needs named administrators and a controlled environment. Expect to provide the following:

Administrative access to MongoDB for the configuration database, including the ability to create and read backups.
Administrative access to the Graylog Data Node cluster or the self-managed OpenSearch cluster, including snapshot repository configuration.
Access to Graylog server configuration files, service accounts and the certificates in use.
A separate restore environment with enough capacity to rebuild the cluster without touching production.

Also name a business owner who can approve restore priorities and confirm which indices and streams matter most. Confirm the exact access model with your security team before the kickoff, since backup administrator accounts often need to be separated from accounts that can change or delete backups.

Can our internal team run a Graylog backup and restore on its own?

Yes, an internal team can run it alone if it has the right skills and enough time. The work needs experience with MongoDB replica sets, the Data Node or OpenSearch snapshot APIs, Linux service management, TLS certificate handling and storage administration. It also needs someone who can write and rehearse a restore runbook in a clean environment. Many teams find the hardest part is not the first backup but proving that a restore works under pressure, with the right order of operations and the right people available. Weigh your team's current workload against those skills. A partner can take on design, build and a restore rehearsal while your staff keeps ownership of the runbook and the recurring tests.

How often should we test Graylog restores?

Test restores at least once a year and again after any substantive change. DORA Article 11(6) requires financial entities, other than microenterprises, to test ICT response and recovery plans at least yearly and after substantive changes, including switchovers to backups and redundant capacity. Substantive changes in a Graylog estate include a major version upgrade, a change to the snapshot repository, a new Data Node cluster layout, a change to certificates or a move of the backing storage. Other frameworks may set different intervals, so confirm the requirement that applies to your organization. A test should restore into a separate environment and record the time taken, the data verified and the issues found.

Does DeployOpen certify that our Graylog backups meet compliance requirements?

No. DeployOpen prepares the systems, documented procedures and test records that an assessment needs, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and decide whether your controls meet a requirement. For backup work, the evidence usually includes the backup policy, the scope of backed-up data, the backup frequency, the restore procedure, access separation and dated restore test results. Ask your auditor which evidence they expect before the project starts, so the test records and runbook are designed to match.

Will the project protect the backups themselves?

The project should cover how backups are protected, not only how they are taken. Confirm three things in the scope: that backup data is encrypted or held separately from the original data, that at least one copy is isolated from the production environment, and that backup administrators cannot silently modify or delete backups during their retention period. These points align with CIS Controls v8.1 Safeguards 11.3 and 11.4 and with the Essential Eight backup requirements. Ask the provider to show how each control is implemented in your environment and which of them you must operate yourselves afterward.

How DeployOpen scopes and delivers Graylog backup and restore

DeployOpen plans, implements, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so Graylog backup and restore is designed around your cluster, your storage and your recovery targets. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the MongoDB configuration data, search backend, server configuration and certificates that a rebuild depends on.
Agree which recovery targets, backup frequency and retention periods your criticality and compliance owners require.
Confirm the backup storage location, encryption approach and separation from the production cluster in the written scope.

How we build

Configure MongoDB and Data Node or OpenSearch snapshot repositories on storage you control, with scheduled jobs and failure alerts.
Back up server configuration, certificates and secrets handling in a way that keeps backup data protected like the original.
Write the restore order for a rebuilt cluster and run a test restore into an isolated environment before handover.

How we hand over

Deliver the backup policy, runbooks and restore procedure documented for your operations and security teams.
Record test restore results, timings observed in your environment and the open items that need your decision.
Walk your platform team through a restore drill so they can repeat it without DeployOpen present.

How we support

Offer ongoing support, upgrades and periodic restore testing as a retainer after the initial handover.
Re-test restores after substantive changes such as Graylog upgrades, search backend changes or storage moves.
Confirm with your team which evidence your auditors or regulators will expect, and provide the backup records that support it.