Skip to main content
Managing onboard storage is one of the few ongoing maintenance tasks the LARK asks of you, and getting it right is important. The appliance has a fixed amount of storage, data accumulates continuously, and when storage fills up the oldest data is overwritten automatically — silently and without warning by default. A straightforward approach to monitoring and offloading keeps you ahead of that rollover behavior and ensures the data you need is available when you need it.

​
Monitor Storage Utilization Regularly

The first habit to establish is checking onboard storage utilization on a routine basis. The admin interface displays current utilization across all storage paths — PCAP, flows, telemetry, alerts, extracted files, and AI outputs — on the Data Management → Storage panel. Each path is shown separately, so you can see which data type is consuming the most space. How frequently you should check depends on your deployment context:
  • High-throughput environments (busy network segments, many active protocols): check daily, or configure alerting thresholds in the admin interface to notify you when utilization crosses a level you define.
  • Medium-throughput environments: check every few days.
  • Low-throughput or intermittent deployments: weekly checks are generally sufficient, but verify after any period of unusually high activity.
Use the storage utilization trend graph in the admin interface to understand how fast each storage path is filling. A few days of trend data lets you predict when you will reach a threshold and plan offloads accordingly.

​
Understand Rollover Behavior

When a storage path reaches capacity, the LARK overwrites the oldest data in that path to make room for incoming data. This is automatic and does not require any action on your part — but it also does not wait for your permission. Once older data has been overwritten, it is gone from the appliance and cannot be recovered locally. Key points about rollover:
  • Rollover is per storage path, not for the entire appliance. A PCAP storage path that is full will roll over PCAP data, but alert records on a separate path are unaffected.
  • The data that is overwritten is always the oldest data in that path. The most recent data is always preserved.
  • Rollover does not generate an alert by default. If you want to be notified before rollover begins, configure a utilization threshold alert in the admin interface.
Do not rely on rollover as a substitute for a proper offload strategy. If a storage path rolls over before you offload, the overwritten data is permanently lost from the appliance. Offloading proactively is the only way to ensure older data is preserved.

​
Set Up Periodic Offloading

Proactive offloading is the most effective way to manage onboard storage. Configuring an offload schedule that runs before storage reaches its capacity limit means that older data is copied to your external infrastructure before the rollover threshold is reached, preserving it while also freeing headroom on the appliance. When configuring your offload schedule:
  • Choose an interval that keeps utilization comfortably below 80% under your typical traffic load. Start with a conservative interval and adjust based on actual utilization trends.
  • If different data types fill at very different rates, consider configuring separate offload schedules for high-volume paths (such as PCAP) and lower-volume paths (such as alerts).
  • After each offload cycle, verify in the admin interface that the job completed successfully and that utilization has decreased as expected.
For instructions on setting up offload destinations and schedules, see Data Offloading. Use the following thresholds as a guide for how to respond to different utilization levels on any storage path:
These thresholds apply to individual storage paths, not to total appliance storage. A path at 90% is a concern even if overall utilization appears lower in aggregate views.

​
Performance Impact of Near-Full Storage

Operating at high storage utilization does not just risk data loss — it also degrades write performance. When a storage path is consistently near capacity, the system spends more resources on rollover management and space reclamation, which competes with the continuous data writes from the capture and processing pipeline. The effects can include increased write latency, slower query response in the admin interface, and reduced offload throughput. Keeping storage below 80% is not just a data preservation recommendation — it is a performance recommendation. Appliances that are routinely run near full capacity will show measurably worse performance compared to those with adequate headroom.
If you observe unexpectedly slow admin interface queries or sluggish offload transfers, check storage utilization first. Freeing space often resolves performance symptoms without any further investigation.

​
Storage Capacity by Data Type

Some data types are inherently higher volume than others, and this affects how quickly individual storage paths fill. As a general guide:
  • PCAP is by far the highest-volume data type and will typically consume the most storage.
  • Flows and telemetry are much more compact than PCAP — typically one to two orders of magnitude smaller for equivalent traffic.
  • Alerts, extracted files, and AI outputs are generally low volume relative to PCAP and telemetry, though extracted file storage can spike during file-heavy transfer events.
If storage constraints are tight, consider whether you need to retain full PCAP on the appliance for all traffic, or whether you can offload PCAP aggressively while keeping flow and telemetry data locally for longer periods.