Remote archive access¶

media.dvr.remote

Sapsan combines recordings of one stream stored on different cluster servers into a shared archive available to viewers. The streamer serving a request locates the required fragment on its peers and retrieves it over the network. The player does not need to know which server recorded the selected moment or which disk stores it.

This allows a camera to move between streamers while retaining access to its history. Old recordings remain on the previous server, and new recordings appear on the new one. Combining the history does not require copying the archive in advance.

A camera moves and the previous server returns¶

Suppose camera cam1 was recorded on streamer A. After A failed, ingest and recording continued on streamer B. Later, A was repaired and returned to the cluster with its disks intact.

After A returns, there is no need to wait for all its history to be copied to B. The cluster uses the retained recordings in place: requests for old moments read A's fragments, while requests for new moments read B's fragments. A does not need to reconnect to the camera or resume recording to do this.

Planned relocation works the same way: the previous streamer can remain in the cluster as a source of old archive data immediately. If a camera has been recorded on several servers in succession, its history can consist of recordings from each of them.

How the cluster finds earlier recordings¶

Central tracks which streamers hold a stream's archive. After relocation, the archive retained on the previous machine is served through an archive remains delivery assignment — dvr_parts.

This assignment keeps the stream on the server for reading existing recordings. It does not ingest the source or create new recordings, but allows other streamers to request its fragments. Storage continues to follow the stream's archive depth.

Central establishes connections to archive servers and authorizes requests between streamers. Relocating a camera does not require manually creating a new list of its previous server addresses for viewers.

A returning streamer must rejoin cluster operation and be eligible to serve archive remains. In particular, the stream's namespace and labels, along with an accessible internal cluster address, are considered. If the archive is assigned only dvr_cleanup, it is cleaned according to retention rules but is not included in remote reads. Assignment conditions are described under archive remains, and addresses under streamer management.

Common fragment addressing¶

A fragment is identified by the stream name, track, and an integer timestamp with its timescale. Its address does not depend on the physical disk or recording server. See archive addressing.

A request for “the fragment of camera cam1 at the selected time” therefore retains its meaning after the camera moves. The server supplying the bytes changes, while the recording's identity stays the same.

Sapsan performs several operations when building a response:

• Merges ranges — collects available intervals from local and remote archives. Actual gaps without recordings remain gaps: merging does not turn them into recorded video.
• Builds fragment lists — combines server results, orders them by time, and removes duplicate entries for the same fragment.
• Reads data — uses an available local source or retrieves the required fragment from a remote streamer, together with the information needed to play it.

For the player, the archive remains the archive of the same stream. Sapsan handles transitions between storage servers; the client does not need to merge A's and B's archives itself.

Access without an advance data transfer¶

Combining the history does not require a job to move the entire archive, additional capacity for a complete copy on the new server, or re-recording old video. Streamers transfer requested data as it is read. Making a large archive available again does not depend on how long a full copy would take.

Remote reading can interact with two other capabilities:

• Archive replication — creates local copies. In the current pipeline, a streamer with DVR recording configured and archive disks can save remotely read fragments into its own archive. This lazy replication is not a prerequisite for accessing the history.
• Archive cache — stores read data on cache disks for subsequent requests and reduced network traffic.

The absence of mandatory migration therefore does not prohibit local copies during playback. Transparent access lets the system use the archive where it already resides; replication and caching additionally change where read data is stored.

History availability¶

Material is available if it has been retained in the archive and resides on a reachable source. While the only server holding an old interval is switched off, its disks cannot be read over the network. Once the server returns and resumes serving recordings, they become part of the shared history again, within the remaining retention period.

To access recordings during a server outage, available archive copies are required. Remote reading uses such copies, but does not create missing recordings or recover intervals during which nobody recorded the camera.

After relocating a camera and bringing the server back, verify the following:

1. The same stream name is retained: the archive is tied to its identity, not just the camera address.
2. The previous server is visible in the cluster and has an archive remains delivery assignment for this stream.
3. Its internal cluster address is reachable from other streamers, and authorization between servers works.
4. Both old and new intervals appear in the history, and moments on either side of the relocation play correctly.

Recording setup is described under DVR, and playback time selection under archive playback.