A deployment team needs to move a directory of application assets into Azure Blob Storage. A developer uses a graphical tool for a few selected files. An operations engineer writes a repeatable transfer command for hundreds of gigabytes. Both approaches can succeed, but their failure modes are different: permissions, path selection, accidental overwrites, unexpected deletions, network reachability, cost, and proving the correct bytes arrived.
Azure Storage Explorer is useful for inspecting and managing supported storage resources through a desktop interface. AzCopy v10 is designed for scripted data movement into, out of, and between supported Azure Storage endpoints. Choosing between them is about control, repeatability, and verification—not which tool has the shorter command or more familiar window.
Choose the transfer method by the problem
Microsoft’s current Microsoft AZ-104 storage objectives explicitly include managing data with Azure Storage Explorer and AzCopy. A successful administrator must distinguish a one-time inspection from an automated copy and a safe upload from a synchronization that may remove destination data.
| Task | Practical starting point | What requires verification |
|---|---|---|
| Inspect a container, properties or a handful of blobs | Storage Explorer | Correct attached resource, identity and actual data-layer permissions |
| Upload or download a few items interactively | Storage Explorer or AzCopy | Exact source and destination paths, and overwrite rules |
| Repeat a large automated transfer | AzCopy copy | Authentication, job outcome, skipped files, transfer volume and costs |
| Align a destination with a source | AzCopy sync, only after careful review | Comparison strategy, deletion behavior and recovery of destination-only items |
| Import physical media or conduct an exceptionally large migration | A specialized data-movement service may be appropriate | Volume, sources, managed workflows, shipping or network availability |
An Azure Blob Storage container provides a boundary for storing objects. A container is not the same thing as a local directory: the operation may target one blob, a virtual folder prefix, all objects under a prefix, or a whole container. Record that scope before granting a role or choosing command flags.
Management visibility is different from data authorization
Seeing an Azure Storage account in the portal does not automatically give its operator permission to download or upload blobs. Azure Resource Manager roles govern the account as a resource; blob data roles and, when applicable, filesystem ACLs govern data access. A user with broad portal visibility may still encounter a permissions error in Storage Explorer or AzCopy.
Microsoft’s current AzCopy guidance identifies Storage Blob Data Reader as an appropriate role for downloading blob data and Storage Blob Data Contributor or another suitably scoped role for uploading. Assign roles at the narrowest useful scope, check role-assignment propagation, and avoid responding to an unexplained data access error by granting subscription-wide Owner.
Hierarchical namespace changes the picture because Azure Data Lake Storage ACLs may govern traversal and directory writes. Azure Files is different again: SMB share permissions and file-level ACLs must be evaluated as separate layers. The Azure Files access model cannot be inferred from a successful blob upload.
Use a safe identity path before moving data
For ordinary interactive use, prefer Microsoft Entra identity and narrowly assigned storage data roles. AzCopy supports azcopy login as well as documented Azure CLI or PowerShell sign-in integrations. Storage Explorer also supports sign-in with Entra ID or attaching supported containers through an authorized identity, with available options depending on the resource.
A shared access signature can delegate narrowly scoped permissions for a limited time when Entra authentication is unsuitable. But a SAS is a bearer credential: a copied URL may permit the holder to perform the authorized operations. Never place a live token in documentation, support tickets or shell examples. The existing account of shared access signatures and stored access policies describes how their permissions and revocation boundaries differ.
Account keys are a broad administrative secret, not a default sign-in mechanism for a team of people. For automation running in Azure, assess the supported managed-identity approach; for other workloads, consider narrowly scoped service principals and governed credential storage. The goal is to make it clear which identity performed a transfer and why that identity had the necessary permissions.
Define a bounded test before starting a transfer
Choose a nonproduction container and record the expected source directory, blob names, file count, total bytes, folder structure, destination owner, permitted overwrites and rollback method. Build an inventory of representative files and meaningful hashes where available. A successful transfer should be measured against that inventory, not just against a progress indicator.
A source manifest can be as simple as an approved list of file paths and expected sizes, but it must establish whether hidden files, subdirectories and recently modified data are in scope. Record the relevant storage tier, whether the account uses a hierarchical namespace, and which application will consume the data afterward. The answer may alter both the permitted transfer operation and the way the final content should be tested.
Confirm the transfer host can resolve and reach the correct Azure Storage endpoint. A workstation connected to an unrestricted network can succeed while a deployment agent in a private virtual network cannot. Check network firewalls, proxies, DNS and any Private Endpoint path from the machine actually running the tool.
Use AzCopy copy for a controlled upload
Install the current supported AzCopy v10 build for your operating system, then authenticate through an approved method. The following examples use imaginary resource names, represent source-backed templates, and have not been executed in an Azure subscription for this article.
azcopy loginWith suitable Microsoft Entra blob data permissions, the source comes first and the target blob URL second. For one file, a POSIX-shell example is:
azcopy copy './reports/summary.csv' 'https://exampleacct.blob.core.windows.net/test-transfer/summary.csv'To include subdirectories, AzCopy supports a recursive option:
azcopy copy './reports' 'https://exampleacct.blob.core.windows.net/test-transfer' --recursiveTo download one object, reverse the direction:
azcopy copy 'https://exampleacct.blob.core.windows.net/test-transfer/summary.csv' './restored/summary.csv'These examples assume the container already exists and that the identity can perform the appropriate operation. Create the container through a supported authorized workflow before copying if necessary. Microsoft notes that single quotes are suitable for common POSIX shells and PowerShell, while Windows Command Prompt uses double quotes. An incorrect quote, wildcard or path delimiter can change the selected data or make the command fail.
A normal copy operation does not automatically remove objects already at the destination but absent from the source. Its overwrite options still matter, however. Review choices such as overwrite-if-newer against your business need before running the command; the source and destination timestamps may be imperfect evidence of intended content. A copied object name and a valid response alone do not prove the application received the desired version.
Understand why AzCopy sync can be more dangerous
AzCopy sync is one-way: one endpoint is the source of truth for the chosen operation and the other is the destination. It compares names and modification timestamps by default, with supported options that alter how differences are detected. It is not an application-level two-way conflict resolver or a guarantee that deleted source data will be recoverable later.
azcopy sync './reports' 'https://exampleacct.blob.core.windows.net/test-transfer' --recursiveDestination deletion must be an intentional decision. Microsoft documents --delete-destination=true to delete destination objects absent from the source without prompting and --delete-destination=prompt to ask before deletion. Neither belongs in a live operation until the exact source set, filters, affected destination prefixes and rollback controls have been reviewed.
A safer pattern for many repeat uploads is copy with a suitable overwrite policy rather than sync with deletion enabled. Microsoft’s performance guidance notes that using copy with --overwrite=ifSourceNewer can avoid an up-front directory scan for large file collections when destination deletions are not needed. That optimization is appropriate only if last-modified-time comparison matches the actual data integrity requirement.
Before using destination-deletion behavior, configure and verify suitable blob versioning and soft-delete recovery. These features have support limitations and retention boundaries; they do not appear automatically just because a transfer or synchronization was started. A narrowly scoped testing operation is far easier to reverse than an account-wide synchronization that removes the only usable copy of a dataset.
Work in Storage Explorer when inspection is central
Storage Explorer offers a resource tree for browsing storage accounts and supported containers, checking blob properties, and carrying out selected copy, upload, download or management operations. It is particularly helpful when an administrator must inspect a few objects before changing a configuration or validate the target after a scripted transfer.
Connect using a supported sign-in or attachment method rather than assuming broad account key access. An identity may be permitted to read blobs in one container without having management-plane permission to list all storage accounts in a subscription. In that case, attaching a resource directly with the supported identity flow can be appropriate. Missing resources in the tree are not proof they were deleted; check the attachment and permission context.
The desktop experience is suited to a human making deliberate, bounded choices. A recurring large transfer needs a repeatable command, documented input manifest, consistent identity and machine-readable job evidence. Moving files through a graphical interface does not remove the need to compare source and destination content or to understand what happens if the operator closes the application midway through a transfer.
Verify a transfer with job evidence and real content
AzCopy reports job results and maintains records to help investigate interrupted or failed transfers. Capture the job identifier, inspect completion versus failed or skipped transfers, and preserve the relevant log and plan files using the supported job commands. A command returning a completed status is stronger evidence than an upload button being clicked, but still does not guarantee that every expected file was in scope.
Compare the approved source manifest with the destination. Check the number of objects, aggregate bytes, path names and representative file content. Download a sample and perform an application-style read wherever the consuming application has distinct file-format or permissions expectations. For some downloads, AzCopy can check an available Content-MD5 blob property, but not every object has such a value; never report comprehensive checksum verification unless it was actually performed.
Filters matter. Recursive operations, wildcard patterns and include/exclude settings can change the file set. Document any intentionally excluded files before the transfer so that missing files are not automatically interpreted as success. If the job only partially succeeded, reconcile the failed entries first. Repeating a broad overwrite command without understanding the failure may increase cost or replace correct data with older versions.
Diagnose authentication, networking and path errors separately
| What the operator sees | Likely boundary | Useful next test |
|---|---|---|
| Storage account visible but blobs unavailable | Data-plane role or directory ACL | Check identity, specific resource scope and required read/list permission |
| Sign-in successful but upload denied | Write role, SAS permission or role propagation | Examine the action actually requested and the effective grants |
| Connection timeouts or failed name resolution | Firewall, DNS, proxy or Private Endpoint path | Test the endpoint from the actual transfer host rather than an administrator laptop |
| Unexpectedly few objects | Source prefix, recursive flag or filter | Compare selection flags and source manifest with the job log |
| Previously existing blobs disappear | Sync destination-deletion policy or another writer | Review command flags, object histories, versioning and recovery state |
| Transfers complete but application data looks wrong | Wrong version, metadata or content | Perform an application-level read and compare expected file identity |
Cross-account transfers require source permissions and destination permissions; success on one side proves nothing about the other. When operations cross regions, account boundaries or tiers, review potential service transactions, outbound transfer charges and storage capacity. A working AzCopy job is not necessarily a well-designed cost or retention policy.
Guard against surprise costs and destructive retries
Large transfers create billable operations, possibly outbound data charges, temporary resource usage and retained versions. Measure the candidate dataset before running a full-scale job. For routine synchronization, count how many items will be scanned as well as how many will be copied. A transfer job can look inexpensive per object and still generate unexpected costs when repeated across millions of objects every few minutes.
Assign an owner for the destination storage account and the retained data. The same Azure cost-accountability discipline that connects usage to workloads should record who initiated the transfer, what it supports, where the copies are retained, and when temporary copies can be removed safely. If the task is a large managed migration, assess Azure Storage Mover and other documented dedicated approaches rather than assuming a single workstation must handle the entire workflow.
Retries should preserve a known source and expected destination state. If a job was interrupted, inspect its logs, verify which items arrived, and resume or repeat only in a supported manner after confirming the overwrite and deletion policies. A team should never activate destination deletion merely to make two directories look identical when that risks erasing the last good copy of critical data.
A controlled practice task that can be audited
Imagine an organization transferring a small set of application templates and images into a new Azure Blob container. The team needs to copy them, verify they are intact, and retain the previous versions until the next release. The responsible administrator begins with the risk and data boundary, not a recursively destructive synchronization command.
- Choose a nonproduction target and verify the storage account and container settings, including protection and retention controls.
- Assign only the required source read and destination write permissions to an approved identity; verify actual endpoint reachability.
- Use Storage Explorer to inspect the source and target structure and record representative blob names and properties.
- Authenticate AzCopy with a documented Microsoft Entra method and perform a small bounded copy with reviewed placeholders replaced by actual approved paths.
- Record the job result, compare source and destination inventory, and read back representative content using the intended consumer identity.
- Compare a second copy run with a suitable overwrite strategy. Do not introduce destination deletion until the team has separately designed and tested its recovery path.
- Document costs, clean-up scope, removed temporary permissions, and evidence that original source information remains usable.
This is a source-informed exercise design, not a claim that the steps were executed in a real subscription. The administrator’s deliverable should be a repeatable and auditable process, not merely a screenshot of a completed upload.
Storage Explorer is best when a person needs to inspect and deliberately manage individual resources. AzCopy is best when the organization needs repeatable data movement with explicit inputs, credentials and evidence. Copy and sync should be treated as different operations with different consequences. The final operational question is not whether a tool reported success; it is whether the right data reached the right destination, stayed secure, and remains recoverable.
