Object storage for Veeam: Skip Glacier for primary backups
Veeam supports four specific cloud vendors plus generic S3 Compatible devices for object storage repositories.
Stop assuming any bucket works for primary backups. The data proves otherwise. Azure Blob Storage Archive and every Amazon S3 Glacier tier will fail direct data backup operations; they support only backup copy jobs. This distinction separates functional architectures from broken ones. You need to understand the hard line between Hot, Cool, and Cold tiers versus their Archive counterparts across providers like IBM Cloud Object Storage and the provider Cloud Object Storage.
The mechanics matter. Veeam Backup for Microsoft 365 isolates metadata in a PersistentCache database on a PostgreSQL instance, keeping it distinct from the bulk data sitting in S3 Compatible systems. Ignore these constraints, and Glacier Deep Archive or Azure Archive targets will render immediate recovery impossible.
The Role of Object Storage Repositories in Veeam Architecture
Object Storage Repository vs JET Database in Veeam
Veeam Backup for Microsoft 365 draws a hard line between local JET database files and scalable Object Storage repositories. JET-based repositories live exclusively on standalone proxy deployments, storing data in Microsoft Jet database (.adb) files on a local disk. If you need a proxy pool, local formats die here. You must implement Object Storage because the local format cannot function in clustered configurations.
Migration to Object Storage buys you efficient compression and native immutability features that guard against ransomware corruption. JET files offer simple local management but cap you at data backup operations only. Rabata.io advises selecting S3-compatible backends immediately for any deployment anticipating future proxy scaling. Waiting until you hit standalone limits forces a painful migration of terabytes of data. The shift to object-based architectures for pooled proxies isn't optional; it keeps data protection strategies viable as organizational needs outgrow single-server constraints.
Proxy Pool Requirements for Object Storage Repositories
Configuring a proxy pool mandates Object Storage as the exclusive repository target. Local JET database options are dead on arrival. This architectural constraint exists because JET-based repositories function only with standalone proxies, forcing scalable deployments to adopt S3-compatible backends.
Operators distinguishing between data backup and backup copy workflows must note that primary ingestion writes compressed data directly to the bucket while metadata tracking uses the PersistentCache database hosted on a PostgreSQL instance. This separation ensures that even if the primary storage tier experiences latency, the indexing layer remains responsive for job orchestration. The system saves metadata separately for each repository to a file located by default in the `C:\Program Files\PostgreSQL\15\data` folder, creating a specific dependency on the PostgreSQL server's disk capacity and I/O performance.
Unlike primary backup jobs which reject cold storage tiers, backup copy operations can target Azure Blob Storage Archive or Amazon S3 Glacier classes for long-term retention. This distinction allows organizations to optimize costs by moving older data to cheaper tiers without altering the active backup pipeline. Monitoring the PostgreSQL data directory growth rate independent of the object storage consumption metrics is necessary for maintaining system health.
Backup and Backup Copy Support Across Repository Types
Operational flexibility depends on selecting a repository type that supports both initial ingestion and secondary replication workflows.
Object Storage repositories uniquely enable the full data lifecycle by supporting both direct data backup jobs and subsequent backup copy operations. This dual capability allows administrators to ingest primary datasets into standard tiers before moving aged data to colder storage classes like Azure Blob Storage Archive or Amazon S3 Glacier Deep Archive. In contrast, JET-based repositories restrict operators to local data backup operations on Microsoft Jet database files, preventing them from serving as targets for backup copy jobs. This architectural limitation forces organizations relying on local.adb files to maintain separate infrastructure for long-term retention strategies.
The cost involves infrastructure complexity versus data durability; JET repositories simplify local deployment yet eliminate the ability to use immutable object locks for ransomware protection. Enterprises requiring immutability must deploy S3-compatible backends to enable valid backup copy chains. Ignoring this constraint leaves primary backups vulnerable to lateral movement attacks that can delete local recovery points. For scalable architectures, Rabata.io recommends prioritizing S3-compatible targets to ensure both immediate availability and compliant long-term preservation.
Mechanisms of Data Protection and Integrity Verification
Mechanics of MD5 and SHA256 Checksum Validation
Veeam Backup for Microsoft 365 calculates hash checksums locally before transmitting data blocks to the target repository. The system computes both MD5 and SHA256 values for Amazon S3 and S3 Compatible endpoints. In contrast, Microsoft Azure Blob storage implementations rely solely on MD5 verification during the upload phase.
The validation process involves calculating checksums before sending data and recalculating them once the data appears in the object storage repository for comparison.
| Storage Platform | Primary Hash | Secondary Hash |
|---|---|---|
| Amazon S3 | MD5 | SHA256 |
| Azure Blob | MD5 | None |
| S3 Compatible | MD5 | SHA256 |
A mismatch indicates data corruption during transfer. In such cases, the data will not be saved to the object storage repository, and the software will attempt to resend the data. This mechanism prevents corrupted data from polluting the backup chain.
Automated Resend Logic for Corrupted Transfer Data
Mismatched checksums immediately trigger an automated resend workflow to prevent saving corrupted data. When Veeam Backup for Microsoft 365 detects a hash discrepancy, it identifies the transfer as compromised and blocks the write operation to the target repository. The system calculates MD5 and SHA256 values locally before transmission, then recalculates them upon arrival at the Object Storage destination. If the values differ, the software discards the corrupted block and initiates a retry sequence without operator intervention. This mechanism ensures that only verified, intact data occupies the backup tier, maintaining a clean recovery point environment.
The software attempts to resend data if checksums differ, ensuring data fidelity. Unlike manual repair processes, this automated logic handles transmission errors directly within the backup job workflow.
| Checksum Type | Supported Repositories | Validation Scope |
|---|---|---|
| MD5 + SHA256 | Amazon S3, S3 Compatible | Full block verification |
| MD5 only | Microsoft Azure Blob | Full block verification |
Enabling Immutability to Prohibit Data Deletion
Administrators must enable immutability during the initial object storage repository addition to prohibit data deletion. This configuration uses underlying cloud capabilities to make stored objects temporarily immutable, creating a rigid barrier against ransomware encryption and accidental user error. This feature allows users to protect data against malware activity by preventing deletion for a specified period.
The primary constraint involves storage class compatibility for data backup jobs. While Object Storage supports various tiers, the Azure Blob Storage Archive access tier and all Amazon S3 Glacier storage classes (including Instant Retrieval, Flexible Retrieval, and Deep Archive) are not applicable for direct data backup jobs. These specific cold storage classes are supported only as targets for backup copy jobs. Consequently, operators must select supported tiers such as Azure Hot, Cool, or Cold, or Amazon S3 Standard and Infrequent Access classes when configuring repositories for primary data backup operations.
- Select a supported storage class during repository creation (e.g. Hot, Cool, Cold, or Standard).
- Activate the immutability flag when adding the repository to enforce temporary write-protection.
Rabata.io recommends validating these settings against your chosen vendor's specific S3 Object Lock implementation to ensure consistent enforcement across hybrid environments.
Strategic Selection of Cloud Storage Classes and Tiers
Defining Azure Blob Tiers and Amazon S3 Glacier Classes
Azure Blob Storage permits direct data backup writes to Hot, Cool, and Cold tiers, reserving the Archive tier exclusively for backup copy operations. Amazon S3 Storage accepts primary ingestion and secondary copying into Standard, Standard-Infrequent Access, and One Zone-Infrequent Access classes. Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive classes reject initial data backup jobs entirely.
This architectural boundary forces a two-stage workflow for deep cold storage deployment. Operators cannot write directly to these tiers during initial job execution. Targeting Glacier Deep Archive or Azure Archive for primary backups causes immediate job failure because these classes lack applicability to data backup scenarios. Administrators must configure separate backup copy jobs to transfer backed-up data from supported tiers into these storage classes.
Veeam Backup for Microsoft 365 supports using Standard or Hot tiers for active recovery points to maintain performance. Backup copy jobs then move data to Glacier or Archive tiers once data ages beyond the immediate recovery window. This approach balances the throughput needs of daily backups with the economic benefits of deep cold storage for long-term retention.
Mapping Retention Needs to AWS Glacier and Azure Cold Tiers
Direct data backup jobs cannot target Amazon S3 Glacier classes or the Azure Blob Storage Archive tier, restricting these options to backup copy tasks exclusively. Administrators selecting storage for active recovery points can apply Azure Cool or Amazon S3 Standard-Infrequent Access to maintain immediate accessibility. The system limits data backup ingestion to supported hot, cool, cold, and standard tiers, reserving deep archive formats for secondary movement of aged data via backup copy jobs.
Operational complications emerge when compliance mandates overlap with storage targets. Selecting a Glacier class for primary ingestion causes job failure rather than automatic tiering. Organizations requiring long-term retention must configure a workflow where initial backups land on standard tiers before copying to deep storage. Best practices suggest mapping retention policies to these technical constraints by designating specific repositories for short-term immutable locks and separate targets for deep archive compliance. This separation prevents accidental exposure of cold data to active write operations while using deep archive pricing models.
Vendor Capability Matrix: S3 Compatible vs Native Cloud Tiers
Native cloud tiers restrict direct backup ingestion to specific access levels, excluding deep archive classes from primary write operations. Azure Blob Storage supports Hot, Cool, and Cold tiers for data backup, yet the Archive tier functions solely as a target for backup copy jobs. Amazon S3 Storage similarly limits direct writes to Standard and Infrequent Access classes, reserving Glacier Instant Retrieval and Deep Archive for secondary movement. Generic S3 Compatible solutions support both data backup and backup copy functions, though specific tiering capabilities vary by vendor implementation. The provider Cloud Object Storage supports both data backup and backup copy activities.
Strict API enforcement drives the operational consequence here. Attempting to write initial backups to unsupported Glacier or Archive buckets triggers immediate job failure rather than automatic promotion. This constraint requires architects to design workflows where active data resides on supported storage before migration via backup copy jobs. Organizations using these native capabilities can use backup copy jobs to move data to low-cost storage layers that are restricted to copy-only scenarios for initial ingestion.
Implementing Object Storage Repositories and Backup Copy Jobs
Implementation: Defining Object Storage Repository Allocation in Veeam Backup for Microsoft 365
Object storage repositories serve as the mandatory foundation for scalable proxy pool architectures, whereas JET-based options remain confined to standalone proxies. This architectural distinction supports expanding enterprises requiring parallel backup streams across multiple nodes. Veeam Backup for Microsoft 365 uses these repositories to store backups for Microsoft 365 and on-premises organizations. Supported systems include S3 Compatible devices, Amazon S3, Microsoft Azure Blob, IBM Cloud Object Storage, and the provider Cloud Object Storage. The platform accepts any S3 Compatible device fully compatible with AWS S3 operations and AWS S3 Signature Version.
The system calculates MD5 and SHA256 checksums before transmission, comparing them upon receipt to validate data integrity automatically. If hashes differ, the software discards the corrupted segment and retries the transfer without user intervention. Organizations aiming for cost-effective, immutable storage at scale should evaluate S3-compatible performance options.
Configuring Immutability and Checksum Validation for S3 Compatible Storage
Administrators can enable immutability when adding an object storage repository to secure data against deletion. This configuration locks the data temporarily, preventing any modification or removal of backup files until the timer expires. The system relies on native encryption features provided by the underlying cloud vendor to complete the security posture.
Data integrity verification occurs automatically before any object is committed to the target bucket. For S3 Compatible targets, the software calculates both MD5 and SHA256 hashes prior to transfer. Upon arrival, the system recalculates these values and compares them against the source hashes. If the checksums differ, the system identifies data corruption and automatically retries the transfer operation without saving the damaged file. Azure Blob Storage targets apply only the MD5 algorithm for this validation process.
Validating hash algorithms maintains data fidelity. During a backup job, data is compressed and backed up directly to the object storage repository. Operators should consider that compression reduces storage requirements while the system handles dual-hash validation on datasets.
Implementation: Pre-Implementation Checklist for Azure Blob Tiers and Amazon S3 Glacier Classes
Verify that your target bucket excludes the Azure Blob Storage Archive tier and all Amazon S3 Glacier classes before creating direct backup jobs. These cold storage formats function exclusively as targets for backup copy operations, rendering them incompatible with initial data ingestion workflows. Veeam Backup for Microsoft 365 supports Azure Blob Storage Archive access tier, Amazon S3 Glacier Instant Retrieval, Amazon S3 Glacier Flexible Retrieval and Amazon S3 Glacier Deep Archive storage classes only as a target for backup copy jobs.
Operational risk lies in misaligning storage class capabilities with job types. Selecting an archive tier for a primary job fails because these tiers are unsupported for direct backup. Administrators must validate tier assignments against job definitions to prevent configuration errors. Proper alignment ensures data protection workflows proceed without interruption across 365 days of operation.
About
Alex Kumar is a Senior Platform Engineer and Infrastructure Architect at Rabata.io, where he specializes in Kubernetes storage architecture and disaster recovery strategies. His daily work involves designing resilient, cost-effective data persistence layers for cloud-native applications, making him uniquely qualified to discuss object storage repositories. At Rabata.io, a provider of high-performance S3-compatible storage, Alex routinely configures backup targets that align with the AWS S3 Signature Version 4 standard. His hands-on experience implementing CSI drivers and optimizing infrastructure-as-code directly informs his understanding of how organizations can use platforms like Veeam Backup for Microsoft 365. By managing multi-cloud strategies that prioritize GDPR compliance and eliminate vendor lock-in, Alex bridges the gap between theoretical storage concepts and practical deployment. This article reflects his real-world insights into selecting storage tiers that balance performance with the rigorous demands of enterprise backup and copy operations.
Conclusion
Scaling direct backup ingestion reveals a hard boundary where storage economics clash with operational mechanics. While hash validation ensures fidelity, the architecture strictly forbids writing primary backups directly to cold storage tiers like Azure Blob Archive or Amazon S3 Glacier classes. This limitation creates a specific operational cost: organizations attempting to bypass standard tiers for immediate cost savings will face total job failures rather than delayed access. The system enforces a hierarchy where warm or hot storage acts as the mandatory landing zone before data can migrate to colder, cheaper layers via copy jobs.
Administrators must reject the assumption that all S3-compatible buckets accept initial backup streams equally. Your strategy should mandate using standard storage classes for all primary backup jobs intended for daily operations. Reserve archive tiers exclusively for secondary copy tasks where long-term retention is the sole objective. This separation prevents configuration dead-ends that halt protection workflows entirely.
Start this week by auditing your existing repository configurations to ensure no primary job targets an unsupported archive tier or Glacier class. Verify that your current buckets allow direct write operations before the next scheduled maintenance window. Aligning these settings now guarantees that your data integrity checks and compression routines execute without hitting immutable storage barriers.
Frequently Asked Questions
Azure Archive and all Glacier tiers fail direct backups. They only support backup copy jobs for long term retention. You must select Hot, Cool, or Standard tiers for primary data ingestion to avoid immediate recovery failures.
Object Storage repositories are mandatory when you configure a proxy pool. JET databases only work with standalone proxies. This architectural rule prevents deployment errors in clustered environments and ensures scalable data protection strategies work correctly.
Metadata saves separately to the PersistentCache database on a PostgreSQL instance. This separation keeps indexing responsive even if primary storage has latency. Default paths reside within the PostgreSQL data folder on the server.
JET-based repositories restrict operators to local data backup operations only. They cannot serve as targets for backup copy jobs. Organizations using local .adb files must migrate to object storage to enable secondary replication workflows.
Dashboards track object counts across four specific Microsoft 365 entity types. These include Users, Groups, Sites, and Teams for comprehensive visibility. Monitoring these distinct categories helps administrators maintain accurate system health metrics effectively.
References
