When restoring archived Graylog logs is the right answer
Restoring archived Graylog logs returns archived messages to a searchable index for a bounded time, so an incident responder or auditor can query events that have already aged out of the hot indices. It is the right answer when the question needs full-text search over specific historical messages, such as reconstructing an access pattern from last year's authentication events or answering a regulator's request for a defined date range. It is usually the wrong answer when you only need to confirm that a log existed, count events over a period, or hand over raw files, because the archive itself can often answer those questions without bringing data back into the search cluster.
Restore is listed as a Graylog Enterprise feature on the Graylog pricing page, and the Enterprise tier also adds the data lake that restore depends on. Graylog Open users therefore cannot plan on restoring archives inside Graylog itself. Confirm the edition you hold before the first incident, not during it. If you are on Graylog Open, the practical options are to query the archived files outside Graylog, restore into a separate OpenSearch or Data Node cluster you operate, or license the capability. Each option has different staffing, storage and evidence-handling consequences, and the decision should be documented in your incident and audit runbooks.
Before committing to a restore, ask three questions: which index sets and time range the request covers, how many messages that represents, and whether the search cluster has room for the restored data alongside live ingest. Write the answers into the request record so the restore scope can be defended later. Check your retention policy and legal hold settings for the same period, since a restore that touches data under hold needs a separate approval path. Your Graylog vendor or implementation partner can confirm how your edition and backend handle these steps in your environment.
How restore needs differ for investigations and audits
An active incident usually needs archived messages quickly, often for a narrow window around the suspicious activity and for a small set of sources such as authentication logs, firewall records or application audit trails. The investigators do not know yet which messages matter, so they may restore a broad slice first and then narrow it. Speed is the main constraint, and the restore competes with live ingest and active searches for the same search backend.
- Time range: Typically the window around first suspicious activity, which the incident lead sets from the evidence available. Confirm the earliest plausible start date with the security team before requesting a restore.
- Speed: Results are needed while the incident is open, so the team should agree a target for first results in the incident runbook.
- Volume: Usually a limited set of streams or sources. Restore only the indices that cover the window, since broad restores slow the cluster for everyone.
- Approver: The incident commander or on-call security lead, with a record of the request kept in the incident ticket.
- Pre-approval: Agree which streams are restorable during an incident before one happens, so the request does not wait for a policy decision.
Before an incident, check that your restore path works by running a small test restore and timing it against your own archive volumes.
Audits and regulator requests usually ask for a defined population of records over a fixed period, with a deadline set by the requester. The work is planned, so the restore can be scheduled outside peak hours and sized in advance. The main risks are an unclear scope, which produces an oversized restore, and incomplete chain of custody, which weakens the evidence even when the messages are found.
- Time range: Set by the request, often a full retention period or a specific reporting period. Confirm the start and end dates in writing with the requester.
- Speed: Usually measured in days against the request deadline, so the restore can run in batches overnight or on weekends.
- Volume: Potentially large. Estimate it from the archive index sizes for the period before scheduling, and agree with the cluster owner when the load window is.
- Approver: Typically the compliance or legal owner who received the request, with the platform owner approving the load impact.
- Documentation: Record the request reference, query, restored index names and the restore dates, so the evidence trail can be shown to an auditor.
Ask the auditor or regulator to state the scope in terms your team can query, such as sources, fields and date ranges.
Routine sampling supports internal controls, such as checking that retention and access logging work as the policy describes, or pulling a small sample to support a control test. These restores are small, predictable and planned on a regular cycle. The goal is to prove the archive is readable and complete, not to answer a live question.
- Time range: A short, fixed sample from different periods across the retention window, so the test covers both recent and older archives.
- Speed: No urgent deadline, so restores can run in a low-load window and results can be reviewed the next working day.
- Volume: Small by design. Choose a fixed sample size in the control procedure rather than restoring whole periods.
- Approver: The control owner signs off the sample plan, and the platform owner confirms the restore does not clash with other work.
- Recurring cost: Sampling creates recurring search backend and storage use each time it runs, so include it in your capacity planning.
Set the sample size, frequency and approver from your own control framework and retention policy, and review them after each assessment.
Restore options and when each one fits
This table compares the choices a team makes before restoring archived Graylog messages: scope, target index set, batching and which node runs the restore. Read each row for its load, retention control and cleanup effort, then confirm the exact restore controls in the Graylog version you run.
| Decision | Option | Trade-off | When it fits |
|---|---|---|---|
| Restore scope | By time range | Smallest search load and data volume; you must know the window the auditor or investigator needs | A defined incident window or a specific audit period |
| Restore scope | By index set | Brings back whole indices, so more storage and search load; easier when the question covers all sources in a stream | Broad questions across a source group, or when time boundaries are unclear |
| Target index set | Existing index set | No new index set to manage, but restored messages mix with live data and affect retention of the source | Short restores where the data can be removed soon after review |
| Target index set | Dedicated index set | Isolates restored data and eases cleanup, but adds an index set to create, name and monitor | Audits or legal holds where the restored data needs its own retention and access |
| Batching | One restore at a time | Lowest load on the search backend and simplest tracking; slower when many periods are needed | Shared production clusters or when search performance is already under pressure |
| Batching | Restores in batches | Faster overall completion, but higher disk and search load and more work to confirm each batch finished | Large audit requests with a fixed deadline and capacity to watch the cluster |
| Restore node | Leader node only | Keeps restore coordination in one place in a multi-node cluster, and the leader is the node that should run it; confirm the behavior in your version | Standard multi-node deployments, following the leader and follower layout in the Graylog multi-node guide |
| Restore node | Follower nodes | Splits work across nodes in ways that may not be supported; confirm before using | Only after the vendor documentation for your version confirms it is supported |
Setup steps for restoring archived Graylog logs
This sequence takes an archived time range from a request to a verified, searchable restore, with each stage confirmed before the next one starts so the investigator receives data that is complete and traceable.
Confirm the edition and archive restore availability
Check the Graylog license with the platform owner and confirm that archive restore is included. Archive restore is listed as an Enterprise feature through the data lake, so Graylog Open alone does not provide it. Confirm the installed version against the Graylog compatibility matrix and check that the search backend is the Data Node or a supported OpenSearch release. The step is done when the license entitlement and the version pairing are written into the restore record. If either is missing, stop here and confirm the path with Graylog before planning further.
Verify archive retention and integrity checks
Ask the archive owner to confirm which time ranges are held in the archive, how long each is kept, and which integrity checks ran when the archives were written. Request the most recent check results and confirm that checksums cover the archive files being restored. Confirm that archive retention has not expired for the period under review, because deletion that ran before archiving cannot be reversed. The step is done when the owner provides a written inventory of the archived ranges with the check results attached to the request.
Size free disk on the search backend
Estimate the volume of the archived messages for the requested range and compare it with free space on the Data Node or OpenSearch hot storage. Graylog's sizing guidance of daily ingest times retention days times 120 percent gives a starting baseline, applied to the restored period rather than the live retention. Account for replicas and leave headroom for the message journal and ongoing ingest. The step is done when the storage team signs off that the target nodes can hold the restored indices without pushing the cluster into read-only or disk watermark conditions.
Set restore scope and a named approver
Define the source streams, the exact time window, the fields and the investigation or audit reference that justifies the restore. Keep the scope as narrow as the question allows, since every extra day adds load and disk use. Name one approver who is accountable for authorizing the restore and recording the reason. The step is done when a written request lists the scope, the approver, and the expected handling of the restored data, and the approver has signed it.
Configure follower nodes and run the restore from the leader
On every follower Graylog node, set is_leader to false in the server configuration so that only the leader runs restore jobs. Confirm the change on each node after restart and check that the load balancer routes search traffic as planned. Start the restore batch from the leader node only, and monitor the restore progress and cluster health during the run. The step is done when all followers report is_leader as false, the restore job completes on the leader, and the cluster status is stable with no unassigned shards.
Verify message counts against the archive
Compare the number of restored messages with the count recorded in the archive inventory for the same time window and streams. Investigate any difference by checking the time boundaries, the stream mapping and any failed batches in the logs. Confirm that timestamps and source fields match the originals. The step is done when the counts reconcile or each discrepancy has a documented explanation and an agreed next action.
Check search results before handing over the data
Run a set of known test searches in the restored index, such as a message that is already documented or a host and event pattern from the request. Confirm that results return with the expected fields and that dashboards or saved searches behave as the investigator needs. Record the queries, the results and the person who checked them. The step is done when the test searches pass and the approver accepts the restored index for the investigator, with access limited to the named scope.
Limits to confirm before restoring archived Graylog logs
A restore only works if the edition, versions, cluster capacity and archive format all line up. The cards below list what to confirm in your own environment before an investigation or audit depends on the restore.
Graylog and search backend versions
Confirm that your Graylog release and your Data Node or OpenSearch version appear together in the compatibility matrix. Graylog 7.0 to 7.2 are listed against MongoDB 7.x up to 8.2.x and OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Use of OpenSearch 1.x is deprecated since Graylog 7.0 and is scheduled for removal in Graylog 8.0, so a restore plan built on an old backend may need an upgrade first. Check the matrix for the exact combination you run, not the newest release line.
Edition that includes archive restore
Archive restore is part of the Graylog Enterprise data lake, not Graylog Open. Confirm the license edition on the cluster that will run the restore, and confirm it covers the processed data volume you expect. Pricing starts at a minimum of 10 GB per day or 100 Graylog Compute Units, and licensing is based on processed data. Ask your vendor or partner which edition and volume tier a restore for your archive size requires, and get that in writing before you rely on it.
Restore throughput the cluster can absorb
Restores write messages back into an index while the cluster still handles live ingest and searches. Measure how much restore load your Data Node or OpenSearch cluster tolerates on a copy of production data, and set batch sizes so the journal does not fill during the restore. Confirm whether restores run on the leader node only, and plan which nodes carry the extra work. Record the throughput you observed so the restore window is based on evidence rather than estimate.
Disk space for restored indices
Restored messages occupy disk in the target index set just like new ingest. Work out the size of each restore batch, add the replica copies your index set template creates, and keep headroom for the message journal and live indices. Use the sizing rule of daily ingest times retention days times 120 percent as a starting point, then confirm the result against the free space on each data node. Restoring a large window into a tight cluster can push active indices toward their limits.
Retention after restored indices expire
Restored indices are not automatically kept forever. Confirm which index set they land in, what rotation and retention that index set applies, and when the restored data will be deleted. If the index set deletes the oldest indices, a restored window may disappear before the investigation closes. Write down the expiry date for each restore and extend it deliberately if the case or audit needs longer access.
Archive format and restore path tested
Do not assume an archive can be read back. Restore a sample from each archive set into a non-production cluster using the same Graylog and backend versions as production. Confirm message counts, timestamps, fields and stream assignments match the original, and check that the checksums recorded at archive time still verify. Keep the test result with the investigation or audit file so you can show the restore path worked before it was needed.
Questions buyers ask about restoring archived Graylog logs
How much does restoring archived Graylog logs cost?
The restore itself is licensed, and the licensing depends on your edition. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year and adds a data lake with archive restore. Enterprise is licensed on processed data, with a minimum of 10 GB per day or 100 Graylog Compute Units, and it carries no per-user or per-device fees. Graylog Open does not provide archive restore, so the license is a prerequisite before any restore can run. Effort costs depend on the volume of archived data, the number of restore batches, the object storage you already pay for, and the hours your engineers or a partner spend. Ask any quote to separate one-time setup of the restore path from recurring license and storage costs.
How long does a Graylog archive restore take?
Restore duration depends on how much data comes back, how quickly the archive storage delivers it, and how much indexing capacity the search backend has free. No general duration applies to every environment, so measure it in yours. Run a test restore of a representative time window, time it, and scale the result to the full request. The variables that move the result are message count and size per day, the number of batches, object storage throughput and region, indexing headroom on Graylog Data Node or OpenSearch, and whether the restore overlaps busy live ingest. Ask a partner to include a timed test in the written scope so the schedule rests on your own measurements.
Can our own team run Graylog archive restores without a partner?
Yes, if you hold the right edition, your staff can operate the search backend and object storage, and the restore procedure is written down and tested. Restores are an operational task, so most failures come from undocumented steps, missing permissions or an untested batch size. Your team needs a runbook covering the request, approval, batch sizing, monitoring, index cleanup and rollback. It also needs named roles, a change window that protects live ingest and someone on call during the restore. Many teams run the first restore with an outside partner, then keep the runbook and train staff to run later restores. Confirm the steps against the version you run, because restore behavior and menus change between releases.
What does our team need to provide for a restore project?
A restore project needs access, decisions and data from your side before any work starts. Engineers need the following to scope and run the restore safely:
Are restored Graylog logs kept permanently after an investigation?
No, not by default. A restored data set lives in an index that consumes hot storage until something removes it, and Graylog removes indices through the retention settings on their index set. According to the Graylog index model documentation, retention can delete the oldest indices as rotation limits are reached. Plan the restored index before the request is approved. Name the target index set, record the case reference and purpose, set a removal date, and delete the index when the case closes. Keep the original archive objects under their own retention rule, so the restored copy never becomes the only record. Confirm the exact removal steps for your Graylog version before you rely on them.
How do we prove to an auditor that restored logs are complete?
Completeness is shown with evidence gathered during the restore, not with a statement that the restore worked. Compare the message count and time range in the archive manifest with the count in the restored index for the same window. Verify checksums on the archived objects before loading them, and keep the restore request, approver, query, batch record and timestamps. Store these records with the case file so the chain from archive to search result is traceable. DeployOpen prepares these controls and evidence for your environment, but independent auditors and certification bodies decide whether the evidence meets a given framework. Agree the evidence list with your auditor before the first restore.
Why do archive restores need the leader node, and what load do they add?
Restores should be scheduled through the leader Graylog node, because the multi-node guide sets is_leader to false on follower nodes. Confirm the restore path for your version before you change any node role. The load falls on the search backend more than on Graylog itself. Restored messages compete with live ingest for indexing throughput, disk I/O, merges and heap, which can grow the message journal if the cluster falls behind. Watch cluster health, indexing rate, disk headroom and journal depth during each batch. Lower the batch size or pause the restore when those signals move past the limits in your runbook.
Security and access controls for restored log data
Restoring archived logs brings back data that was deliberately moved out of the search cluster, so it needs its own access decisions. The cards below cover who may ask for a restore, how restored data is exposed, how restores are recorded, how the archive is protected and when restored data is removed. Confirm each item against your own Graylog edition and configuration before the first restore.
Who may request and approve restores
Decide which roles can start a restore, which person must approve it and how that approval is recorded outside Graylog. Restores can expose years of messages from many sources, so a single analyst should not be able to pull a broad time range alone. Confirm with your Graylog edition and role model which permissions gate restore actions, and test that a user without the restore permission cannot trigger one. Document the approval path in your investigation procedure.
Access rules on restored indices
Check whether a restored index inherits the stream, index set and role permissions of the original data, or whether it needs its own grants. A restored index that is visible to a wider group than the source logs can leak data to people who were never authorized for it. Compare what a restricted user can search before and after a test restore. Record the result so an auditor can see the access boundary for that restore.
Audit records of each restore
Make sure every restore is traceable to a person, a time range, a source index set and a reason. Confirm whether Graylog's audit output captures restore requests and completions, and where it is stored. If the platform does not record the reason or the approver, keep that information in your ticketing system and link the ticket to the restore. An auditor will ask who restored which data, when, and why.
Protection of archive storage and keys
Treat the archive bucket or file repository as sensitive storage. Confirm who can read, write and delete archived objects, how access is granted to the Graylog service account, and whether objects are encrypted at rest with keys you control. Restrict key administration to a separate team from log administration. Test that a restore fails cleanly when credentials are revoked, so you know the boundary works.
Deletion after the investigation closes
Set a rule for removing restored indices once the investigation or audit request is closed. Restored data is a second copy of records that may already be past their retention period, so leaving it online extends exposure. Confirm how Graylog deletes a restored index, whether deletion is logged, and that the archive copy remains under its own retention. Record the deletion date in the case file.
What drives the cost of restoring archived Graylog logs
The cost of a restore is spread across four components, and only one of them is a clear line item. The first is the Graylog license. Restoring archived data into a searchable index is a feature of Graylog Enterprise, which adds a data lake with archive restore. The Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user fees. That figure recurs annually and does not change with the number of restores you run, but it is the base cost for any team that needs restores as a managed capability. Confirm with Graylog whether the minimum volume tier fits your daily ingest and whether restored data counts toward the licensed volume in your quote.
The second component is search backend capacity. A restored index needs heap, shards and disk on your Data Node or OpenSearch cluster while it is searchable, and a large restore can compete with live ingest and dashboards for the same resources. Ask the provider to state how restore load is capped and what extra nodes, if any, are assumed. The third component is staff time for scoping and verification: choosing the time range and streams, confirming the restored message count matches the archive, and documenting who requested the data. This effort is mostly one-time per request but recurs with every investigation or audit cycle, so ask whether it is priced per request or covered by a retainer.
The fourth component is disk held until restored data is removed. Restored indices consume storage until someone deletes them, and that storage is often forgotten after the case closes. Ask for a written cleanup step with an owner and a date, and ask whether the quote includes deleting restored indices and verifying that the cluster returns to its baseline capacity. Request a quote that separates license, backend capacity assumptions, verification effort and post-restore cleanup, so each cost can be compared against your own team's time.
How DeployOpen scopes and delivers archive restore work
DeployOpen treats restoring archived Graylog logs as a defined piece of work with its own scope, not an ad hoc task run during an incident. We agree in writing which archives, time ranges, restore batches and target indices are in play, then build and document the procedure so your team can repeat it under audit pressure.
How we scope
- Inventory which archived streams, index sets and time ranges your investigations and auditors are likely to request
- Confirm the archive backend, its access path and the Graylog edition that provides archive restore
- Agree restore batch sizes, leader-only restore handling and the search backend capacity available during restores
- Define the storage the restored indices will occupy and the date they are removed after the review closes
How we build
- Configure the restore procedure on your Graylog nodes with the follower and leader roles set as your multi-node design requires
- Set restore batches and test them against a representative archive so search load on the backend is measured, not guessed
- Verify restored messages match archived counts and timestamps before any investigation relies on them
- Record the checks and their results so the chain of custody can be reviewed later
How we hand over
- Written runbook covering request intake, restore steps, cleanup of restored indices and escalation contacts
- Configuration and change records for the restore setup, kept in your infrastructure and version control
- Walkthrough with the investigators and compliance staff who will request restores and review the output
- Clear list of what must be confirmed with your Graylog edition, licensing and archive storage owners before go-live
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer for restore procedures after handover
- Re-testing of restore batches when Graylog, the search backend or the archive storage is upgraded
- Quotes follow from the written scope, so ask for the components, assumptions and recurring items to be listed
