{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/separate-proxmox-live-restore-from-start-after-restore/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/",
        "slug": "separate-proxmox-live-restore-from-start-after-restore",
        "url": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/separate-proxmox-live-restore-from-start-after-restore/"
        },
        "title": "Separate Proxmox live restore from start-after-restore",
        "summary": "Choose the documented PBS-only live-restore path deliberately and keep it distinct from starting a VM after a successful restore.",
        "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": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "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-29T17:41:02+00:00",
        "modified_at": "2026-10-29T17:41:38+00:00",
        "reviewed_on": "2026-10-29",
        "reading_minutes": 3,
        "word_count": 503,
        "potentially_affected": "Proxmox VE administrators restoring QemuServer vzdump backups with qmrestore.",
        "dse_recommendation": "Specify restore mode, target identity and storage before rehearsing an isolated VM recovery.",
        "primary_source": {
            "name": "Proxmox — qmrestore(1)",
            "url": "https://pve.proxmox.com/pve-docs/qmrestore.1.html",
            "published_on": null,
            "authority": "pve.proxmox.com"
        },
        "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": "<p><strong>Bottom line:</strong> Decide when the recovered VM may start before approving the restore command. Keep early start, completed restoration and application acceptance as separate milestones, with the intended VM identity and storage written down.</p>\n<h2>Source fact: what the authority says</h2>\n<p>The <a href=\"https://pve.proxmox.com/pve-docs/qmrestore.1.html\" target=\"_blank\" rel=\"noopener noreferrer\">Proxmox qmrestore manual</a> documents <code>--live-restore</code> as starting the VM immediately while restoration continues in the background, for PBS only. Its separate <code>--start</code> option starts the VM after it has been restored successfully and defaults to disabled. Without a specified storage target, restored volumes are allocated on their original storage. The manual exposes <code>--force</code> to allow overwriting an existing VM and <code>--unique</code> to assign a random unique Ethernet address.</p>\n<h2>What the source does not establish</h2>\n<p>This command reference establishes option meanings, not an application recovery-time guarantee or a qualification of guest behavior during background restore. This article does not approve overwriting an existing VM or reconnecting a recovered copy to production networks.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>Is the backup source PBS and is early VM startup actually required?</li>\n<li>Which unused or expressly approved VM ID will receive the restore?</li>\n<li>Which target storage and network identity are intended?</li>\n<li>What evidence separately establishes restore completion and usable application recovery?</li>\n</ul>\n<h2>DSE recommendation: controlled next steps</h2>\n<p><em>The following steps are DSE recommendations based on the cited source.</em></p>\n<p>DSE recommends a restore request with distinct fields for archive, VM ID, storage and startup mode. Require the recovery owner to choose ordinary completion followed by startup or the documented PBS live-restore branch. Avoid treating the two startup options as interchangeable conveniences.</p>\n<p>Review existing VM identity before adding any overwrite option. For a proposed isolated recovery copy, decide the intended Ethernet address and network attachment with the network owner. Do not add <code>--force</code> merely because the first command encounters a conflict that has not been investigated.</p>\n<p>Select target storage explicitly when the recovery design requires a different destination. Review the available destination and approved workload envelope before the run. Keep any bandwidth cap as a separately justified choice and confirm its units against the current manual rather than inventing a rate.</p>\n<p>Define a proposed harmless application check and a separate restore-completion check. Assign an owner to each milestone, including the decision about when users may connect. Preserve the original backup and keep the recovered instance isolated until identity and service checks are accepted.</p>\n<h2>Verification and evidence</h2>\n<p>Proposed verification: restore an approved test backup into the agreed isolated target and record the effective options, selected storage and startup observations. If live restore is the selected branch, capture VM startup and the independently observed end of background restoration as two events.</p>\n<p>Exercise the named application check only within the authorized test network and preserve actual results. Inspect the resulting VM identity before allowing wider connectivity. Retain the archive reference, command result and acceptance decisions together; a running VM alone must not close a still-unresolved restore-completion question.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://pve.proxmox.com/pve-docs/qmrestore.1.html\" target=\"_blank\" rel=\"noopener noreferrer\">Proxmox — qmrestore(1)</a> — official product documentation; confirm the installed release and configuration.</li>\n</ul>\n<p>Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.</p>\n",
        "content_text": "Bottom line: Decide when the recovered VM may start before approving the restore command. Keep early start, completed restoration and application acceptance as separate milestones, with the intended VM identity and storage written down.\nSource fact: what the authority says\nThe Proxmox qmrestore manual documents --live-restore as starting the VM immediately while restoration continues in the background, for PBS only. Its separate --start option starts the VM after it has been restored successfully and defaults to disabled. Without a specified storage target, restored volumes are allocated on their original storage. The manual exposes --force to allow overwriting an existing VM and --unique to assign a random unique Ethernet address.\nWhat the source does not establish\nThis command reference establishes option meanings, not an application recovery-time guarantee or a qualification of guest behavior during background restore. This article does not approve overwriting an existing VM or reconnecting a recovered copy to production networks.\nApplicability questions\n\nIs the backup source PBS and is early VM startup actually required?\nWhich unused or expressly approved VM ID will receive the restore?\nWhich target storage and network identity are intended?\nWhat evidence separately establishes restore completion and usable application recovery?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a restore request with distinct fields for archive, VM ID, storage and startup mode. Require the recovery owner to choose ordinary completion followed by startup or the documented PBS live-restore branch. Avoid treating the two startup options as interchangeable conveniences.\nReview existing VM identity before adding any overwrite option. For a proposed isolated recovery copy, decide the intended Ethernet address and network attachment with the network owner. Do not add --force merely because the first command encounters a conflict that has not been investigated.\nSelect target storage explicitly when the recovery design requires a different destination. Review the available destination and approved workload envelope before the run. Keep any bandwidth cap as a separately justified choice and confirm its units against the current manual rather than inventing a rate.\nDefine a proposed harmless application check and a separate restore-completion check. Assign an owner to each milestone, including the decision about when users may connect. Preserve the original backup and keep the recovered instance isolated until identity and service checks are accepted.\nVerification and evidence\nProposed verification: restore an approved test backup into the agreed isolated target and record the effective options, selected storage and startup observations. If live restore is the selected branch, capture VM startup and the independently observed end of background restoration as two events.\nExercise the named application check only within the authorized test network and preserve actual results. Inspect the resulting VM identity before allowing wider connectivity. Retain the archive reference, command result and acceptance decisions together; a running VM alone must not close a still-unresolved restore-completion question.\nOfficial references\n\nProxmox — qmrestore(1) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.",
        "content_markdown": "Bottom line: Decide when the recovered VM may start before approving the restore command. Keep early start, completed restoration and application acceptance as separate milestones, with the intended VM identity and storage written down.\n\n## Source fact: what the authority says\n\nThe [Proxmox qmrestore manual](https://pve.proxmox.com/pve-docs/qmrestore.1.html) documents --live-restore as starting the VM immediately while restoration continues in the background, for PBS only. Its separate --start option starts the VM after it has been restored successfully and defaults to disabled. Without a specified storage target, restored volumes are allocated on their original storage. The manual exposes --force to allow overwriting an existing VM and --unique to assign a random unique Ethernet address.\n\n## What the source does not establish\n\nThis command reference establishes option meanings, not an application recovery-time guarantee or a qualification of guest behavior during background restore. This article does not approve overwriting an existing VM or reconnecting a recovered copy to production networks.\n\n## Applicability questions\n\n- Is the backup source PBS and is early VM startup actually required?\n\n- Which unused or expressly approved VM ID will receive the restore?\n\n- Which target storage and network identity are intended?\n\n- What evidence separately establishes restore completion and usable application recovery?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a restore request with distinct fields for archive, VM ID, storage and startup mode. Require the recovery owner to choose ordinary completion followed by startup or the documented PBS live-restore branch. Avoid treating the two startup options as interchangeable conveniences.\n\nReview existing VM identity before adding any overwrite option. For a proposed isolated recovery copy, decide the intended Ethernet address and network attachment with the network owner. Do not add --force merely because the first command encounters a conflict that has not been investigated.\n\nSelect target storage explicitly when the recovery design requires a different destination. Review the available destination and approved workload envelope before the run. Keep any bandwidth cap as a separately justified choice and confirm its units against the current manual rather than inventing a rate.\n\nDefine a proposed harmless application check and a separate restore-completion check. Assign an owner to each milestone, including the decision about when users may connect. Preserve the original backup and keep the recovered instance isolated until identity and service checks are accepted.\n\n## Verification and evidence\n\nProposed verification: restore an approved test backup into the agreed isolated target and record the effective options, selected storage and startup observations. If live restore is the selected branch, capture VM startup and the independently observed end of background restoration as two events.\n\nExercise the named application check only within the authorized test network and preserve actual results. Inspect the resulting VM identity before allowing wider connectivity. Retain the archive reference, command result and acceptance decisions together; a running VM alone must not close a still-unresolved restore-completion question.\n\n## Official references\n\n- [Proxmox — qmrestore(1)](https://pve.proxmox.com/pve-docs/qmrestore.1.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change."
    },
    "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/separate-proxmox-live-restore-from-start-after-restore/",
                "url": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-29"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/#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": "Separate Proxmox live restore from start-after-restore",
                        "item": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/#article",
                "identifier": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/",
                "url": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/",
                "headline": "Separate Proxmox live restore from start-after-restore",
                "description": "Choose the documented PBS-only live-restore path deliberately and keep it distinct from starting a VM after a successful restore.",
                "abstract": "Choose the documented PBS-only live-restore path deliberately and keep it distinct from starting a VM after a successful restore.",
                "articleBody": "Bottom line: Decide when the recovered VM may start before approving the restore command. Keep early start, completed restoration and application acceptance as separate milestones, with the intended VM identity and storage written down.\nSource fact: what the authority says\nThe Proxmox qmrestore manual documents --live-restore as starting the VM immediately while restoration continues in the background, for PBS only. Its separate --start option starts the VM after it has been restored successfully and defaults to disabled. Without a specified storage target, restored volumes are allocated on their original storage. The manual exposes --force to allow overwriting an existing VM and --unique to assign a random unique Ethernet address.\nWhat the source does not establish\nThis command reference establishes option meanings, not an application recovery-time guarantee or a qualification of guest behavior during background restore. This article does not approve overwriting an existing VM or reconnecting a recovered copy to production networks.\nApplicability questions\n\nIs the backup source PBS and is early VM startup actually required?\nWhich unused or expressly approved VM ID will receive the restore?\nWhich target storage and network identity are intended?\nWhat evidence separately establishes restore completion and usable application recovery?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a restore request with distinct fields for archive, VM ID, storage and startup mode. Require the recovery owner to choose ordinary completion followed by startup or the documented PBS live-restore branch. Avoid treating the two startup options as interchangeable conveniences.\nReview existing VM identity before adding any overwrite option. For a proposed isolated recovery copy, decide the intended Ethernet address and network attachment with the network owner. Do not add --force merely because the first command encounters a conflict that has not been investigated.\nSelect target storage explicitly when the recovery design requires a different destination. Review the available destination and approved workload envelope before the run. Keep any bandwidth cap as a separately justified choice and confirm its units against the current manual rather than inventing a rate.\nDefine a proposed harmless application check and a separate restore-completion check. Assign an owner to each milestone, including the decision about when users may connect. Preserve the original backup and keep the recovered instance isolated until identity and service checks are accepted.\nVerification and evidence\nProposed verification: restore an approved test backup into the agreed isolated target and record the effective options, selected storage and startup observations. If live restore is the selected branch, capture VM startup and the independently observed end of background restoration as two events.\nExercise the named application check only within the authorized test network and preserve actual results. Inspect the resulting VM identity before allowing wider connectivity. Retain the archive reference, command result and acceptance decisions together; a running VM alone must not close a still-unresolved restore-completion question.\nOfficial references\n\nProxmox — qmrestore(1) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.",
                "datePublished": "2026-10-29T17:41:02+00:00",
                "dateModified": "2026-10-29T17:41:38+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/separate-proxmox-live-restore-from-start-after-restore/"
                },
                "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/separate-proxmox-live-restore-from-start-after-restore/#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": "Separate Proxmox live restore from start-after-restore"
                },
                "articleSection": [
                    "Business Continuity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Business Continuity",
                    "Networks & Infrastructure",
                    "Guide",
                    "Advisory priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Business Continuity",
                        "url": "https://update.dsesecurity.com/topic/business-continuity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 503,
                "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": "Proxmox — qmrestore(1)",
                    "url": "https://pve.proxmox.com/pve-docs/qmrestore.1.html"
                }
            }
        ]
    }
}