Proxmox Backup to NAS: NFS vs SMB Setup and Restore Checklist

Preparation date: September 17, 2026. Scope: This is a documentation-based implementation and verification guide, not a claim about a completed customer incident. It covers ordinary Proxmox VE VZDump backups written to NAS storage. A Proxmox Backup Server datastore is a different architecture and is called out separately. The short answer is: choose NFS when Proxmox is the main consumer and your NAS can restrict the export to the Proxmox node addresses. Choose SMB/CIFS when the same share must also fit a Windows-oriented operating model or your NAS administration is already built around named users and SMB permissions. The protocol choice matters, but the restore test matters more. A green backup task proves that an archive was written; it does not prove that you can recover a VM on replacement storage. Proxmox backup to NAS verification flow A Proxmox node writes a VZDump backup over NFS or SMB to a NAS, then a separate restore test validates recovery. ...
Post a Comment

Storage CRC and Invalid Tx Word Counters: Identify the Path Before Replacing Parts

Identify the counter's source and transport before interpreting CRC or “Invalid Tx Word Count.” A counter observed on an ESXi Fibre Channel adapter is not the same as an Ethernet switch counter or an array-side alert. This guide builds an evidence record before replacing parts.

Correction, September 12, 2026: The previous article mixed Fibre Channel and Ethernet terminology, supplied generic switch commands, and recommended moving ports/clearing counters without preservation or path-impact checks. Those instructions have been removed. The original replacement history is not treated as a verified diagnosis here.

Record the complete path

EvidenceRecord explicitly
Counter originProduct, version, exact label, interface/HBA and time.
TopologyHost adapter, fabric/switch ports, array port, active paths and redundancy.
Error trendTwo or more time-stamped values and whether counters reset or wrap.
ImpactI/O latency/errors, path changes and application symptoms in the same interval.
Recent workExact cable/optic/port changed, supported part identification and before/after evidence.

Broadcom KB 413619 discusses these counters in an ESXi/SAN context. Broadcom KB 401254 provides another relevant counter example. Neither is a universal decoder for every Pure Storage or switch alert. Match the platform and obtain the appropriate array/fabric documentation through support.

Use deltas before resetting anything

A historical cumulative count alone does not establish a continuing fault. Preserve the initial values, compare subsequent values under representative traffic, and account for resets. Do not clear counters merely to make a dashboard green. Correlate error growth with both ends of the physical path and the host's I/O observations.

Inspect supported optics, cabling, negotiated settings and environmental observations with the fabric/storage owners. Optical readings require the installed component's limits; an arbitrary number or imbalance is not sufficient to identify a failed part. Do not apply Ethernet FEC advice to a Fibre Channel path by analogy.

Plan a single-variable isolation test

Before moving a cable or port, verify multipathing and remaining path health, storage access configuration, capacity for failover and a maintenance window. A redundant diagram is not proof that the surviving path currently works. Coordinate any zoning, port or hardware change with the owners and retain the original mapping.

Change one supported component or setting, then compare error deltas and workload health. Stop if path availability or I/O degrades. Do not move multiple links together or restart an array controller to test a hypothesis. Restore the prior approved configuration when safe and escalate if the evidence remains ambiguous.

Closure criteria

Document stable paths, representative workload behavior and whether new errors stopped during an agreed interval. Do not rule out software solely because physical-layer evidence exists, or declare the entire array faulty from one counter. Supply sanitized topology, versions, trend and change records to the relevant vendors.

Related troubleshooting guides

Comments

Post a Comment

Popular posts from this blog

Horizon vdpConnect_Failure: Connection-Stage Triage Before Reinstalling

vdpConnect_Failure is a starting symptom, not a root-cause diagnosis. Before reinstalling Horizon Agent or opening firewall ports, establish whether the failure occurs during authentication, desktop launch, or an established session. This documentation-based triage guide does not report a reproduced incident or a universal fix. Corrected September 12, 2026: The earlier guide suggested restarting the Windows RPC service and treated a local netstat listing as a test for blocked ports. Those instructions have been removed. A socket listing does not demonstrate end-to-end reachability. Classify the failure before making changes Observation First evidence to collect Avoid assuming Authentication never completes Exact login error, identity provider or broker event, timestamp That the display protocol is the failing component. Desktop selection succeeds, launch fails Assigned desktop, chosen protocol, Client/Agent and gateway logs That a successful HTTPS login proves the session path ...
Read more

Horizon Agent Unreachable: Registration and Desktop-Health Triage

Start an “Agent Unreachable” investigation by separating desktop health, Agent registration, and session traffic. Do not begin with a pool rebuild. This documentation-based triage guide helps decide which team should act and what evidence to preserve. Correction, September 12, 2026: The earlier guide mixed display ports with Agent communication, tested Blast against the Connection Server, and offered generic service restarts and image rebuilds. Those instructions have been replaced with path-specific investigation. First-response decision table Check Evidence Investigation owner Is the guest responsive? Approved console access, OS health, resource and disk observations Desktop/virtualization team if the OS is unavailable. Is this one desktop or a whole image family? Affected pool, image revision, Agent version, start time Image owner if failures align with a deployment. Does registration fail? Agent and Connection Server events for the same desktop and time Horizon team, then netw...
Read more

Horizon Protocol Error: Trace the Display-Session Handoff

A desktop can authenticate successfully and still fail to establish its display session. This guide investigates that handoff. Use it after identifying the actual console/client error, not as a claim that every “Protocol Error” means a firewall failure. Correction, September 12, 2026: The previous version combined a general checklist with an unverified incident narrative, conflated gateway and desktop port directions, and recommended blanket endpoint-security exclusions. Those instructions have been removed. This is a documentation-based diagnostic plan. Draw the attempted connection Record the selected protocol, assigned desktop, Client and Agent versions, gateway route, and attempt time. Distinguish a direct internal connection from an external UAG connection or a Connection Server tunnel. Use Omnissa's connection guide to identify where the failed handoff occurs. Stage Question Useful comparison Authentication Did the user receive desktop entitlement? Failed login versus ...
Read more