{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/preserve-queued-axis-failover-objects-before-removing-their-destination/", "item": { "id": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/", "slug": "preserve-queued-axis-failover-objects-before-removing-their-destination", "url": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination.md", "json": "https://update.dsesecurity.com/api/v1/posts/preserve-queued-axis-failover-objects-before-removing-their-destination/" }, "title": "Preserve queued Axis failover objects before removing their destination", "summary": "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.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T00:10:27+00:00", "modified_at": "2026-10-29T00:10:34+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 511, "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.", "primary_source": { "name": "Axis Communications — Remote object storage", "url": "https://developer.axis.com/vapix/device-configuration/remote-object-storage-api/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source fact: documented behavior

\n

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

\n

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

\n

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

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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

\n
    \n
  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. \n
  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. \n
  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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "Bottom line: Treat removal of a remote storage destination as a potential evidence-loss operation, especially while an upload backlog remains unresolved.\nSource fact: documented behavior\nThe Remote object storage documentation says removing a destination also removes all objects held in failover for that destination.\nObjects held only in memory are lost if the device loses power before upload or writing to failover storage.\nThe documented failover behavior automatically reuploads stored objects when the connection is restored.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nWhich destination is being changed, and why is removal being proposed?\nCould that destination still have objects in failover or memory?\nWhat supported evidence can establish which required recordings reached durable storage?\nWho can defer deletion and power-related work while recovery status remains uncertain?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a recovery checkpoint before any planned removal of a remote recording destination.\n\nPut 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.\nFor 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.\nBefore 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.\n\nVerification and evidence\nRetain 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.\nInclude 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.\nOfficial references\n\nRemote object storage — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Treat removal of a remote storage destination as a potential evidence-loss operation, especially while an upload backlog remains unresolved.\n\n## Source fact: documented behavior\n\nThe [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.\n\nObjects held only in memory are lost if the device loses power before upload or writing to failover storage.\n\nThe documented failover behavior automatically reuploads stored objects when the connection is restored.\n\n## What the source does not establish\n\nDo 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.\n\n## Applicability questions\n\n- Which destination is being changed, and why is removal being proposed?\n\n- Could that destination still have objects in failover or memory?\n\n- What supported evidence can establish which required recordings reached durable storage?\n\n- Who can defer deletion and power-related work while recovery status remains uncertain?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a recovery checkpoint before any planned removal of a remote recording destination.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nRetain 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.\n\nInclude 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.\n\n## Official references\n\n- [Remote object storage](https://developer.axis.com/vapix/device-configuration/remote-object-storage-api/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/", "url": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Preserve queued Axis failover objects before removing their destination", "item": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/#article", "identifier": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/", "url": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/", "headline": "Preserve queued Axis failover objects before removing their destination", "description": "Removing an Axis remote-object-storage destination also removes its queued failover objects.", "abstract": "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.", "articleBody": "Bottom line: Treat removal of a remote storage destination as a potential evidence-loss operation, especially while an upload backlog remains unresolved.\nSource fact: documented behavior\nThe Remote object storage documentation says removing a destination also removes all objects held in failover for that destination.\nObjects held only in memory are lost if the device loses power before upload or writing to failover storage.\nThe documented failover behavior automatically reuploads stored objects when the connection is restored.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nWhich destination is being changed, and why is removal being proposed?\nCould that destination still have objects in failover or memory?\nWhat supported evidence can establish which required recordings reached durable storage?\nWho can defer deletion and power-related work while recovery status remains uncertain?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a recovery checkpoint before any planned removal of a remote recording destination.\n\nPut 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.\nFor 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.\nBefore 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.\n\nVerification and evidence\nRetain 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.\nInclude 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.\nOfficial references\n\nRemote object storage — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T00:10:27+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/preserve-queued-axis-failover-objects-before-removing-their-destination/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Preserve queued Axis failover objects before removing their destination" }, "articleSection": [ "Business Continuity", "Video Surveillance" ], "keywords": [ "Business Continuity", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 511, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — Remote object storage", "url": "https://developer.axis.com/vapix/device-configuration/remote-object-storage-api/" } } ] } }