| 1 | --- |
| 2 | title: Snapshot & restore (cold storage) |
| 3 | description: Offload old indexes into snapshot repositories and restore them later when needed. |
| 4 | --- |
| 5 | |
| 6 | # Snapshot & restore (cold storage) |
| 7 | |
| 8 | **Menu:** Indices → Snapshot & Restore |
| 9 | |
| 10 | **Best for:** Admin / Engineer |
| 11 | |
| 12 | Snapshots let you **offload older indexes into cold storage** (snapshot repositories) so you can make room for new events while still keeping the ability to restore history later. |
| 13 | |
| 14 |  |
| 15 | |
| 16 | --- |
| 17 | |
| 18 | ## When to use snapshots |
| 19 | |
| 20 | Use snapshots when you need to: |
| 21 | - reduce disk usage on the indexer |
| 22 | - keep long-term historical logs without keeping them “hot” |
| 23 | - preserve data before major maintenance/changes |
| 24 | |
| 25 | --- |
| 26 | |
| 27 | ## Repository registration is required |
| 28 | |
| 29 | CoPilot can manage snapshots, but the snapshot **repository must exist and be registered** in the Wazuh Indexer cluster first. |
| 30 | |
| 31 | In the UI you’ll see this warning if none exist: |
| 32 | |
| 33 | > “Snapshot repositories must be manually registered in your Wazuh Indexer cluster …” |
| 34 | |
| 35 |  |
| 36 | |
| 37 | --- |
| 38 | |
| 39 | ## Step 1 — Verify repositories |
| 40 | |
| 41 | 1) Open **Indices → Snapshot & Restore** |
| 42 | 2) Click **Repositories** |
| 43 | 3) Confirm at least one repository exists and is healthy |
| 44 | |
| 45 | --- |
| 46 | |
| 47 | ## Step 2 — Create a snapshot |
| 48 | |
| 49 |  |
| 50 | |
| 51 | 1) Go to **Snapshots** |
| 52 | 2) Choose the repository |
| 53 | 3) Select the index/index pattern(s) to snapshot |
| 54 | 4) Run the snapshot |
| 55 | |
| 56 | --- |
| 57 | |
| 58 | ## Step 3 — Restore a snapshot (when you need old data) |
| 59 | |
| 60 |  |
| 61 | |
| 62 | Restoring brings historical data back so you can: |
| 63 | - investigate an incident with older timelines |
| 64 | - run retro-hunts |
| 65 | - rebuild context for cases |
| 66 | |
| 67 | --- |
| 68 | |
| 69 | ## Step 4 — Schedule snapshots (automation) |
| 70 | |
| 71 |  |
| 72 | |
| 73 | If you regularly offload older logs, scheduled snapshots help keep disk usage stable. |
| 74 | |
| 75 | ### Schedule window (time-of-day + day interval) |
| 76 | |
| 77 | By default a snapshot schedule is evaluated every 15 minutes — and if there are new indices to snapshot, it fires immediately. That can mean snapshot operations hit the Wazuh Indexer during business hours, when the cluster is busiest. |
| 78 | |
| 79 | Each schedule has four optional fields that pin execution to a maintenance window: |
| 80 | |
| 81 | | Field | Type | Purpose | |
| 82 | |---|---|---| |
| 83 | | **Day of Week** | `Monday … Sunday` (or empty) | Restrict execution to a single weekday. Empty = any day. | |
| 84 | | **Scheduled Hour** | `0–23` (or empty) | Hour of day the schedule is allowed to run. Empty = any hour (legacy behavior — runs every poll). | |
| 85 | | **Scheduled Minute** | `0–59` (or empty) | Minute of hour. Pairs with Scheduled Hour to form a **15-minute window** starting at this minute. Empty = any minute in the chosen hour. Disabled until Scheduled Hour is set. | |
| 86 | | **Interval (Days)** | `≥ 1`, default `1` | Minimum days between executions. `1` = at most once per day. `14` paired with **Day of Week** = "every other Sunday". | |
| 87 | | **Timezone** | IANA name, default `UTC` | Used to evaluate Day of Week / Scheduled Hour / Scheduled Minute. Examples: `UTC`, `America/Chicago`, `Europe/London`. DST is handled automatically. | |
| 88 | |
| 89 | When the current time is outside the window, the schedule's **Last Execution** column shows a `DEFERRED` tag and **no Wazuh Indexer API calls are made** — there's effectively zero cluster load on deferred polls. The next poll inside the window picks up where it left off, and the existing "no new indices = SKIPPED" deduplication still applies. |
| 90 | |
| 91 | #### Example — daily at 02:00 UTC |
| 92 | |
| 93 | | Field | Value | |
| 94 | |---|---| |
| 95 | | Scheduled Hour | `2` | |
| 96 | | Scheduled Minute | `0` | |
| 97 | | Interval (Days) | `1` | |
| 98 | | Timezone | `UTC` | |
| 99 | |
| 100 | Result: between 02:00 and 02:14 UTC each day, the schedule fires (assuming new indices exist). All other polls are deferred. |
| 101 | |
| 102 | #### Example — weekly on Sunday at 01:00 US Central |
| 103 | |
| 104 | | Field | Value | |
| 105 | |---|---| |
| 106 | | Day of Week | `Sunday` | |
| 107 | | Scheduled Hour | `1` | |
| 108 | | Scheduled Minute | `0` | |
| 109 | | Interval (Days) | `1` | |
| 110 | | Timezone | `America/Chicago` | |
| 111 | |
| 112 | > `America/Chicago` correctly handles US Central time year-round — CST in winter (UTC-6) and CDT in summer (UTC-5). |
| 113 | |
| 114 | Result: only fires on Sundays between 01:00 and 01:14 Central. All other days/times defer. |
| 115 | |
| 116 | #### Example — every other Sunday at 01:00 US Central |
| 117 | |
| 118 | | Field | Value | |
| 119 | |---|---| |
| 120 | | Day of Week | `Sunday` | |
| 121 | | Scheduled Hour | `1` | |
| 122 | | Scheduled Minute | `0` | |
| 123 | | Interval (Days) | `14` | |
| 124 | | Timezone | `America/Chicago` | |
| 125 | |
| 126 | The `Interval (Days) = 14` blocks runs for 13 days after the last successful execution, so the next eligible Sunday after a fired run lands exactly two weeks later. |
| 127 | |
| 128 | #### Backward compatibility |
| 129 | |
| 130 | Schedules created before this feature was introduced — and any new schedule where Scheduled Hour is left empty — keep their original behavior: they run on every 15-minute poll and rely solely on the "new indices needed" check. |
| 131 | |
| 132 | --- |
| 133 | |
| 134 | ## Common gotchas |
| 135 | |
| 136 | ### “No snapshot repositories found” |
| 137 | A repository must be registered in the Wazuh Indexer cluster before snapshots can run. |
| 138 | |
| 139 | ### “Snapshots succeed but disk is still full” |
| 140 | Snapshots don’t automatically delete hot indexes. You still need a retention plan: |
| 141 | - delete old indexes (with intent) |
| 142 | - reduce ingestion volume |
| 143 | - tune retention windows |