Adding an object storage repository to a Veeam deployment looks like a five minute task. A bucket, a folder, a credential, a checkbox for immutability, done before the coffee gets cold. Several of those fields turn out to be close to permanent, since changing them later means either a new repository and a fresh set of full backups, or a migration planned around locks nobody can shorten. The useful work happens before the wizard opens.
The reflex is to accept sensible defaults and adjust once the environment settles. That works in a lab. In production it does not, because an object storage repository is not a folder that can be renamed. Backup chains reference objects under a specific prefix, immutability holds objects for a period that cannot be cut short, and the repository record carries the bucket, the path and the credential as part of its identity.
A Veeam object storage repository points at a bucket and, usually, a folder inside it. Everything it writes lives under that prefix. Renaming is not an operation the backup software offers, so the name chosen in the first ten minutes appears in change tickets, firewall rules and restore procedures for as long as the repository exists.
Two questions matter more than the naming convention. The first is whether one bucket will serve more than one backup server. Sharing is possible when each server gets its own folder, but it couples them: a bucket level policy or a credential rotation now touches both. The second is whether the prefix expresses something durable. Site, backup server and purpose survive reorganizations. A department name or a year does not, and objects written under a bad prefix cannot be moved before the lock expires.
The single repository is attractive: one thing to monitor, one credential, one capacity number. It also means every job shares one retention behavior, one immutability period and one failure domain.
Splitting by purpose is usually the better default, and the axis that matters is rarely the department. It is the retention and immutability profile. Data held for thirty days and data held for seven years age out differently and make a shared capacity number hard to interpret.
The second axis is ownership. Backups of the virtualization estate, backups taken by Veeam Agent on physical machines, and copies destined for a second site have different owners, restore paths and growth curves. Where a repository sizing exercise produced separate numbers for each, separate repositories keep those numbers meaningful. The counterweight is operational load, since each one is another credential, another threshold and another line in the runbook.
Immutability on a Veeam object storage repository depends on the bucket supporting S3 Object Lock, and on that support being in place before the repository is added. Object Lock is a bucket property, and on most S3 implementations it is enabled at bucket creation rather than afterward. A bucket created without it generally has to be replaced rather than upgraded, so this is the decision most likely to force a rebuild if left for later.
The immutability period is separate from the retention the job enforces, and the two interact. Veeam applies a lock to the objects it writes and extends it as the chain grows, so the period during which data cannot be deleted is not simply the number typed into the repository settings. How the two compound has varied across releases, so the honest approach is to confirm the behavior in the deployment at hand and reserve capacity for the longer figure.
There is also a mode question. Object Lock offers governance and compliance modes, differing in whether a privileged identity can lift a hold early. Governance mode is recoverable from a mistake. Compliance mode is not, by design. That is a policy conversation involving whoever owns the retention requirement, not a checkbox for whoever builds the repository.
| Decision | Why it is awkward to change later | What to settle in advance |
|---|---|---|
| Bucket and folder path | The repository cannot be renamed and locked objects cannot move | A prefix tied to site, server and purpose |
| One repository or several | Splitting later means new chains or a migration | One repository per retention and immutability profile |
| Object Lock on the bucket | Usually enabled only at bucket creation | Whether this data needs immutability at all |
| Immutability period and mode | Locked objects hold capacity until the lock expires | The period, the mode and the capacity both imply |
| Gateway arrangement | Changing it alters the data path and the firewall rules | Which hosts reach the storage, on which network |
| Credential scope | Rotating a shared key affects every consumer of it | One identity per repository, limited to its own prefix |
Veeam reaches object storage either through a designated gateway server or by letting the relevant components connect directly, depending on the repository configuration. The choice determines which machines need a route to the storage and where traffic concentrates during a backup window. A single gateway is easy to reason about and easy to make into a bottleneck. Direct connection spreads the load and the firewall surface with it. Where storage sits on a segmented network reachable only from specific hosts, the placement of the gateway is effectively a network design decision other teams have to agree to.
How the repository is addressed belongs in the same conversation. A hostname, a matching certificate, and name resolution that works from every machine that needs it are easier to establish once than to change under pressure. Addressing storage by IP address works until the address changes or a certificate has to be presented, at which point every entry that referenced it needs editing.
The credential is the last item and the one handled most casually. A key created for a proof of concept, with broad permissions, often survives into production because nothing forced its replacement. A repository should have an identity of its own, scoped to its own bucket or prefix, with no reuse elsewhere. That scoping makes rotation possible without an outage, and it is part of the wider question of what a backup service account should be able to do.
ARTESCA is object storage software used as a backup target, deployed on infrastructure the customer runs. It presents an S3-compatible API and supports immutability through S3 Object Lock, so a Veeam object storage repository is configured against it as it would be against any other S3 endpoint: an endpoint address, a bucket, a folder, a credential, and an immutability setting where one is required.
Because deployment is on customer infrastructure, the planning items that involve network boundaries, certificates, name resolution and key management stay under the customer's control. That is an advantage when gateway and addressing decisions have to satisfy an internal network design, and a responsibility when nobody has written those decisions down.
ARTESCA covers roughly 50 TB to several petabytes and is commonly sold alongside Veeam through resellers, so one conversation often produces both the sizing figure and the repository layout. Settling bucket structure, immutability and credential scope there is cheaper than revisiting them once chains exist.
A short written record covers most of this. For each repository planned, note the bucket and folder, the owning backup server, whether Object Lock is enabled, the immutability period and mode, the gateway arrangement, the endpoint name, and the identity it authenticates with. Six lines per repository doubles as the document a colleague needs to rebuild it.
Before the first production job, one test exercises the awkward parts together: write a small backup, confirm the objects appear under the expected prefix, attempt a deletion that should be refused, and restore through the intended network path. That catches a missing lock, a wrong prefix and an unreachable gateway in one pass, while the repository is still empty enough to rebuild.
Review that record whenever a new workload is pointed at an existing repository. That is the moment a retention profile quietly changes and a repository built for one purpose starts serving another. Catching it there is a five minute conversation. Catching it later is a migration.