Preserve queued Axis failover objects before removing their destination

Bottom line: Treat removal of a remote storage destination as a potential evidence-loss operation, especially while an upload backlog remains unresolved.

Source fact: documented behavior

The Remote object storage documentation says removing a destination also removes all objects held in failover for that destination.

Objects held only in memory are lost if the device loses power before upload or writing to failover storage.

The documented failover behavior automatically reuploads stored objects when the connection is restored.

What the source does not establish

Do not use this API description as proof that a particular destination’s backlog has been recovered. Keep destination deletion separate from credential correction, connectivity repair and recording acceptance. Confirm the installed product’s supported observation and recovery methods before acting. Do not assume a successful configuration request proves that required recordings are available to an investigator.

Applicability questions

• Which destination is being changed, and why is removal being proposed?
• Could that destination still have objects in failover or memory?
• What supported evidence can establish which required recordings reached durable storage?
• Who can defer deletion and power-related work while recovery status remains uncertain?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a recovery checkpoint before any planned removal of a remote recording destination.

1. Put the destination identifier and reason for change on a short decision record. Ask the recording owner whether any incident interval or unresolved outage requires preservation. Distinguish a configuration-cleanup request from a decision that may discard queued data. If status is uncertain, pause the removal and get the supported recovery procedure from the responsible manufacturer or integration supplier.
2. For a proposed disposable-data pilot, create an upload interruption through an approved test arrangement. Plan how the team will observe failover state and later confirm retrieval of the marked recording interval. Restore the connection and follow the supported recovery process before considering destination removal. Do not delete the only copy of required footage to demonstrate the documented behavior.
3. Before a production migration, agree what evidence must exist at the receiving store and who will verify it. Compare the required intervals with what an authorized reviewer can actually retrieve. Resolve missing or ambiguous intervals before deleting the old destination. Coordinate any power-related maintenance with the same recovery decision, rather than treating camera reboot and destination cleanup as unrelated work.

Verification and evidence

Retain the destination identity, outage and recovery timeline, supported state observations and retrieved test material. Record the person who confirmed preservation and the scope of that confirmation. Keep credentials and storage tokens out of the change record.

Include a stopped-work case in the proposed rehearsal: the recovery status is unknown, so deletion remains deferred and the request returns to the recording owner. That is a valid test outcome for the process. This article does not report a live outage, a successful upload recovery or a guarantee of recording continuity.

Official references

• Remote object storage — Axis Communications; official VAPIX documentation.

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.