# Preserve queued Axis failover objects before removing their destination > Removing an Axis remote-object-storage destination also removes its queued failover objects. Review recovery data before deleting a destination during an outage or migration. - Canonical URL: https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:27+00:00 - Modified: 2026-10-29T00:10:34+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Video Surveillance - Reading time: 3 minutes ## What you need to know Removing an Axis remote-object-storage destination also removes its queued failover objects. Review recovery data before deleting a destination during an outage or migration. ## Potentially affected Axis devices exposing the documented Remote object storage interface; confirm support and the installed API/software scope before applying the proposed checks. ## DSE recommendation DSE recommends a recovery checkpoint before any planned removal of a remote recording destination. ## Article 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](https://developer.axis.com/vapix/device-configuration/remote-object-storage-api/) 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. - 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. - 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. - 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](https://developer.axis.com/vapix/device-configuration/remote-object-storage-api/) — 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. ## Primary reference - Name: Axis Communications — Remote object storage - Authority: Axis Communications - URL: https://developer.axis.com/vapix/device-configuration/remote-object-storage-api/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve queued Axis failover objects before removing their destination,” DSE Security, https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.