# Key RMF Backfill Features ### Availability RMF 8.0.0 - May 2026 ### Overview
RMF Backfill restores video continuity across active-active redundant Milestone XProtect recorders after an outage. When a Primary or Secondary recorder goes offline: for maintenance, a network drop, a hardware failure, or any other reason, its peer keeps recording. Once the offline recorder returns, **Backfill copies the missed footage from the peer that stayed online**, so both sides of the redundant pair end up with the same continuous timeline. The transfer happens **peer-to-peer between recording servers**, on a schedule and bandwidth budget you control from the Management Client. There is no external broker, no manual file copy, and no operator intervention required. *** ### How It Works Backfill runs as a lightweight Windows service — **BackFillService** — installed on every XProtect recording server that participates in RMF. The service is managed centrally from the Management Client under **MIP Plug-ins → RMF → BackFill**. When a recorder comes back online, its Backfill service: 1. Identifies the time window during which it was unreachable. 2. Looks up its **redundancy correspondence:** the same Primary↔Secondary mapping established during RMF configuration to determine which peer recorder holds the missed video for each of its cameras. 3. Requests the missing media from that peer over a dedicated port. 4. Writes the recovered video into local storage so playback, export, and evidence workflows behave as if the recorder was never down. Because Backfill reuses RMF's existing redundancy correspondence, no additional camera-by-camera mapping is needed. If RMF knows where a camera's redundant copy lives, Backfill knows where to fetch it. *** ### The Flow Dashboard The **Flow Dashboard** gives a live, at-a-glance view of every recorder participating in Backfill. Primary servers appear on the left, Secondary servers on the right, with animated flow lines connecting redundant peers. Each server card shows its online state, camera count, and whether Backfill is currently enabled (`BACKFILL ON`).
When a recorder is offline, its card and flow line shift state so operators can see, without drilling into logs, exactly where redundancy is currently degraded.
*** ### The Configuration View The **Configuration** tab lists every recording server in the deployment along with its current Backfill status: service state, uptime, number of backfills performed, and total data transferred.
From here, an administrator can: * Enable or disable Backfill per recorder. * Set the **listening port** and **target drive** for backfilled media. * Define a **bandwidth throttling schedule** so that peer-to-peer transfers don't compete with peak corporate network traffic. * Restart or refresh the service.
#### Bandwidth Throttling The throttling schedule accepts multiple time windows, each with its own MB/s ceiling. A typical pattern is generous overnight, restrictive during business hours, and moderate in the evening — letting Backfill catch up quickly when the network is quiet without disrupting daytime operations. *** ### Backfill History Each recorder maintains a **Backfill History** showing the most recent transfer jobs: the time range that was recovered, when the request was issued, how much video was moved, and how long it took. The full history is available for download for audit and reporting.
### Redundancy Correspondence: What Backfill Supports RMF allows administrators to model redundancy in whichever way fits the deployment, and Backfill follows the same model. #### Server-to-Server Correspondence All cameras on a Primary recorder are mirrored onto a single Secondary recorder. See [Mode Selection](/redundancy-management-framework/user-manual/configuration-dashboard/mode-selection.md). * **Symmetric:** one Primary maps to one Secondary (1:1).
* **Asymmetric:** many Primaries consolidate onto fewer Secondaries (N: M, N>M)
#### At-Will Correspondence Cameras on Primary recorders are distributed across Secondary recorders in any user-defined arrangement, allowing maximum flexibility. See: [Mode Selection](/redundancy-management-framework/user-manual/configuration-dashboard/mode-selection.md)
Backfill supports **all** modes. When a recorder returns from an outage, its service consults the correspondence map and retrieves each camera's missing video from whichever peer holds it, even if that means contacting multiple peers to recover a single recorder. *** ### Asymmetric Retention Policies A camera's storage profile on a Primary recorder does not have to match its storage profile on the Secondary. Retention periods, archive schedules, live/archive tier boundaries, and storage locations can all differ between the two sides. Backfill handles this transparently. When a recorder returns from an outage, Backfill: 1. Fetches the missing media from whichever peer holds it, regardless of how that peer has tiered the footage. 2. Consults the **local** storage profile on the returning recorder. 3. Deposits each block of recovered video into the correct tier — **live**, **archive 1**, **archive 2**, and so on — exactly where it would have landed had the recorder never gone offline. The only requirement is that the content still exists somewhere on the peer. The peer's retention policy, archive structure, and disk layout are irrelevant to the destination; Backfill always honors the **returning recorder's own** storage rules.
#### Example 1: Shorter Live Window on Secondary A Primary keeps 7 days of live recording before archiving; the Secondary keeps only 2 days of live before archiving to colder storage. A Primary goes offline for 4 days. On return, it backfills from the Secondary. Some of the requested videos are still in the Secondary's live tier; others are already in the Secondary's archive. Backfill pulls both and deposits them into the **Primary's** live tier — because on the Primary, 4-day-old footage is still within the live window.
#### Example 2: Longer Retention on Secondary A Secondary site is configured as the long-term retention tier: 90 days total, with 7 days in live and 83 days in archive. The Primary keeps only 30 days, all in live. A Secondary recorder goes offline for **three weeks**. When it returns, it backfills the 21-day gap from the Primary. On the Primary, all 21 days are in live; on the Secondary's profile, the most recent 7 days are in live storage, and the older 14 days are in the archive. Backfill deposits the recovered video accordingly, **routing each day of footage to the correct local tier based on the Secondary's own retention rules**, not the Primary's.
#### Why This Matters Symmetric storage profiles force customers to over-provision the cheaper site or under-retain at the more expensive one. Backfill's profile-aware deposit logic removes that constraint: **each site keeps the storage profile that makes sense for its role**, and redundancy still works correctly across the mismatch. *** ### Architectures Supported Backfill is designed to work across every architecture RMF itself supports: * **Single-site** — recorders share one XProtect deployment with a clustered Management Server / SQL.
* **Federated** — recorders belong to a Parent site and one or more Child sites.
* **Independent sites** — each site is its own XProtect deployment, joined only by RMF.
*** ### XProtect Variants Supported It also works across every XProtect product tier: * XProtect Express+ * XProtect Professional+ * XProtect Expert * XProtect Corporate *** ### Limitations #### Platform Support Dependency RMF Backfill is not a native Milestone XProtect feature. It operates by reading from and writing to the XProtect media database independently of XProtect's own recording pipeline. Because of this, **changes to XProtect's internal media database format — which Milestone may make at any time without notice — can break Backfill's ability to read, transfer, or deposit video.** Vega Systems works to keep Backfill compatible with each XProtect release, but the media database format is not a published API. In the event of a breaking change, a fix may depend on collaborative engagement from Milestone. There is no guarantee that every format change can be accommodated, or that a fix can be delivered. #### Edge Recording Exclusion Cameras that support edge recording and cameras that rely on RMF Backfill must be assigned to **separate recorder pairs**. Edge-recording cameras go on a dedicated redundant pair with Backfill **disabled**; Backfill cameras go on their own dedicated redundant pair with Backfill **enabled**. The two groups must not share a recorder. Backfill is unnecessary for edge-recording cameras. When a recorder in the pair comes back online after an outage, it independently retrieves the missing content directly from each camera's onboard storage. No peer-to-peer transfer between recorders is involved.
#### Recording Server Encryption XProtect recorders must **not** be configured to encrypt content before writing to disk. Encrypted content cannot be transferred by the Backfill application. Ensure that media database encryption is disabled on all recorders participating in Backfill.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.vega25.com/redundancy-management-framework/user-manual/backfill/key-rmf-backfill-features.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.