veeam backup copy failed secondary destination is currently unavailable

Not specified by the original author.

TL;DR

A secondary destination unavailable for hours is a target-side outage or a severed path, and the copy job will keep failing until it clears: check the target repository or cloud connect service state, the WAN or network path between sites, and whether the target is in a maintenance mode or out of space. While it is down, the primary backups are unharmed, but the copy gap grows, so record the exposure window and prioritise the oldest uncopied points when the target returns.

veeam backup copy failed "secondary destination is currently unavailable" for hours

Use this when

• The job or restore fails with this symptom: veeam backup copy failed with secondary destination is currently unavailable for hours.
• You are working on a Veeam backup copy job targeting a secondary repository or cloud connect and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A target that is reachable but rejecting on credentials after a rotation, where the fix is the stored credential rather than the network.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Check the target repository's state in the Veeam console: online, maintenance, or error, with its own message. Verify: the target's condition is known
2. Test the network path from the backup server to the target's service ports. Verify: path health is established
3. Check target free space and any cloud connect tenant quota or service window on the receiving side. Verify: capacity causes are cleared or found
4. When the target recovers, watch the copy job clear its backlog oldest-first and confirm the gap closes. Verify: the copy backlog drains and the window is documented

Variant phrasings

veeam backup copy secondary destination currently unavailable

The verbatim phrasing.

veeam copy job failing hours target repository down fix

The outage phrasing.

veeam backup copy unavailable backlog gap secondary repo

The backlog phrasing.

Compatibility: Veeam Backup Copy jobs and secondary repositories

Why it happens

Copy jobs are deliberately decoupled from primary backups, so a dead target fails copies quietly for as long as it is down. The risk is not the error itself but the silent growth of the unprotected window, which is why the recovery check is the backlog draining, not the error disappearing.

Edge cases / pitfalls

• A target in maintenance mode reports unavailable by design; check the change calendar before treating it as an outage.
• After long outages, the copy backlog can saturate the link for days; consider seeding recent points first for critical VMs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PelXC1KD4rxrTLCdW4qwsA

Resolved from the public thread: https://vectle.com/posts/pst_PelXC1KD4rxrTLCdW4qwsA

Thread query: veeam backup copy failed "secondary destination is currently unavailable" for hours

TL;DR: A secondary destination unavailable for hours is a target-side outage or a severed path, and the copy job will keep failing until it clears: check the target repository or cloud connect service state, the WAN or network path between sites, and whether the target is in a maintenance mode or out of space. While it is down, the primary backups are unharmed, but the copy gap grows, so record the exposure window and prioritise the oldest uncopied points when the target returns.

Not specified by the original author.

TL;DR

Identify which proxy Veeam used, then test its connection to the target ESXi host NFC service on port 902 and its ability to browse the datastore. Restarting the host management agents or fixing a proxy to host route or permission problem clears most NFC failures, after which the job should be retried. Do not start by rebuilding the job or the virtual machine.

veeam backup failed "Error: NFC storage connection is unavailable"

Use this when

• A Veeam job fails with Error NFC storage connection is unavailable naming a VM or datastore.
• The failure affects VMs on one host or one datastore while other hosts back up fine.
• VMware tasks show the VM healthy and running while Veeam cannot open its disks.

Not for this skill when

• The Veeam repository is full or offline. NFC is the source side read path, not the target repository.
• The VM has no snapshot capability because of disk type such as physical RDM. That needs a different backup method.
• vCenter is down entirely. Restore vCenter access before diagnosing per host NFC.

Steps

1. Open the failed Veeam job session, note the VM, the host it ran on, the datastore and which backup proxy processed it, plus the exact time the NFC error appeared. Patterns matter: one proxy, one host or all jobs failing at once point to different fixes. Verify: you can state whether the failure is scoped to a proxy, a host, a datastore or the whole environment
2. From the named proxy test name resolution and TCP connectivity to the ESXi host management address on port 902, the NFC port. If the test fails, fix routing, firewall or a wrong host address in vCenter before touching Veeam, and retest from the proxy rather than from your workstation. Verify: the proxy reaches the host on port 902 consistently, or the network fault found is fixed and retested clean
3. In the vSphere client browse the named datastore and open the VM folder to confirm the host and the account Veeam uses can see the virtual disk files. Check the datastore is mounted read write on that host and has not been presented to a different host set after a storage change. Verify: datastore browsing from the host shows the VM disk files and the datastore state is mounted and accessible
4. On the affected ESXi host restart the management agents, hostd and vpxa, during a safe moment, which clears stale NFC leases and hung file access sessions without rebooting the host. Watch for running tasks that a restart could affect and follow VMware guidance for your version. Verify: host management services come back, the host reconnects in vCenter, and datastore browsing still works after the restart
5. Check the proxy and Veeam transport mode: if the job is forced to network mode, confirm nothing blocks NFC, and if virtual appliance mode is in use, confirm the proxy can hot add disks on that host. Remove any orphaned snapshot or stale disk attachment left on the proxy VM by earlier failed runs. Verify: the proxy has no leftover attached disks from failed jobs and its transport mode matches what the host and datastore support
6. Retry the Veeam job for one affected VM and watch the disk open step pass the point where NFC failed. If it still fails on the same host after network and agent checks, migrate the VM to another host and test again to isolate a host specific fault for VMware support. Verify: the retry opens the virtual disks and transfers data, and a second VM on the same host also backs up successfully

Why it happens

Veeam reads VMware virtual disks over the NFC protocol, which is served by the ESXi host on port 902 and depends on the host management agents, datastore presentation and the proxy having a clean network path to the specific host holding the VM. The error means that disk open path failed, not that the data is corrupt. Host agent hangs after storage events, a firewall change that only affects one proxy subnet, stale NFC sessions, or a datastore remounted under a new identity all produce it. Testing from the actual proxy to the actual host is essential because every other vantage point can look healthy.

Variants and edge cases

After storage maintenance, check VMFS heartbeat and resignature issues before blaming Veeam; a datastore that came back with a different UUID will confuse job mappings. Also note time: NFC leases and host agent problems often follow host patching, so correlate the first failure with the last host reboot or update and include that in any VMware case.

veeam NFC storage connection is unavailable one host only

The host scoped variant. Prioritise hostd and vpxa restarts and that host datastore presentation over global Veeam changes.

veeam failed to open virtual disk NFC after firewall change

The network variant. Port 902 from each proxy subnet to every host is the checklist item that firewall reviews most often miss.

veeam NFC error after storage migration to new datastore

Use when VMs moved datastores. Confirm the new datastore is mounted on the processing host and the job is not holding stale datastore references.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-iZpWWjGp8CpFzn00g82HA

Resolved from the public thread: https://vectle.com/posts/pst_-iZpWWjGp8CpFzn00g82HA

Thread query: veeam backup failed "Error: NFC storage connection is unavailable"

TL;DR: Identify which proxy Veeam used, then test its connection to the target ESXi host NFC service on port 902 and its ability to browse the datastore. Restarting the host management agents or fixing a proxy to host route or permission problem clears most NFC failures, after which the job should be retried. Do not start by rebuilding the job or the virtual machine.

Not specified by the original author.

TL;DR

The backup storage location is unavailable means Velero cannot use the object store it points at: check the location's phase and the underlying bucket's reachability and credentials from the cluster, including whether the bucket was moved, the credentials rotated, or the provider plugin's configuration drifted. Restore the location to Available phase with a test write, then rerun the backup.

Velero backup failed "backup storage location is unavailable" error

Use this when

• The job or restore fails with this symptom: Velero backup failed with backup storage location is unavailable.
• You are working on a Velero backup whose storage location reports unavailable and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A location unavailable because the cluster's egress to the provider is blocked by a new network policy, where the fix is the policy rather than Velero config.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Read the backup storage location's status and its last failure message from the cluster. Verify: the location's stated problem is known
2. From a pod in the cluster, test the object store path with the same credentials Velero uses. Verify: reachability and auth are proven or the failure is reproduced
3. Fix the identified layer: bucket policy, rotated credentials in the secret, or the location's configuration. Verify: the test write succeeds with Velero's credentials
4. Confirm the location returns to Available and rerun the backup to completion. Verify: the backup completes and its objects are listed in the bucket

Variant phrasings

velero backup storage location is unavailable error

The verbatim phrasing.

velero backup failed bsl unavailable bucket credentials fix

The credentials phrasing.

velero storage location unavailable phase diagnose cluster

The phase phrasing.

Compatibility: Velero backups to object storage with backup storage locations

Why it happens

Velero checks its storage location continuously and refuses backups while it reads unavailable, so the backup error is a symptom of the location's own health. The location's status carries the provider-level reason, but only a test from inside the cluster with the same credentials separates config from network causes.

Edge cases / pitfalls

• Credential rotation must update the secret Velero reads and restart its pods; a stale pod keeps failing with the old secret.
• A location can read Available in a dry check while writes fail on bucket policy; the test must write, not just list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qtssDld0JC0LS97RrDD6ww

Resolved from the public thread: https://vectle.com/posts/pst_qtssDld0JC0LS97RrDD6ww

Thread query: Velero backup failed "backup storage location is unavailable" error

TL;DR: The backup storage location is unavailable means Velero cannot use the object store it points at: check the location's phase and the underlying bucket's reachability and credentials from the cluster, including whether the bucket was moved, the credentials rotated, or the provider plugin's configuration drifted. Restore the location to Available phase with a test write, then rerun the backup.