Backup repatriation is the decision to bring backup data that lives in a public cloud back to storage the organization runs itself. It usually follows a period of rising invoices, a restore that took longer or cost more than expected, or a new requirement about where data may be held. The decision is the easy part. The move itself involves years of restore points, immutability locks that cannot be shortened and transfer charges on the way out.
This post covers how a backup repatriation is planned, what moves and what does not, and how to avoid paying for two full copies longer than necessary.
Why organizations repatriate backups
Three reasons come up most often. The first is cost: capacity, request and retrieval charges have grown with retention until the monthly total exceeds what on-premises storage would cost over its life. The second is recovery time: restoring a large data set over a wide-area link is slower than restoring from the same building. The third is control: a regulator, a customer contract or an internal policy now asks that backup data stay in a named jurisdiction or on infrastructure the organization operates.
Where cloud backup bills grow breaks down the cost side in more detail.
Two ways to make the move
| Approach | How it works | Trade-off |
|---|---|---|
| Redirect and age out | New backups go to the on-premises target, cloud copies expire under their existing retention | No egress for old data, but both targets run until the longest retention ends |
| Copy back, then switch | Existing restore points are copied to the new target before the cloud repository is closed | One repository sooner, at the price of egress and transfer time |
| Selective copy | Only long-term restore points are copied, short-term ones age out | Lower egress, more planning to decide what moves |
Redirect and age out
The lowest-cost path for most estates is to stop writing to the cloud and let what is there expire. New backup jobs, or the existing jobs pointed at a new repository, begin with a full backup on the on-premises target. The cloud repository becomes read-only in practice and shrinks as retention runs down. After 30 or 90 days, most short-term data has gone, and the remaining volume consists of monthly and yearly points.
The overlap needs managing. Both repositories must stay healthy and reachable, and a restore may need to come from either depending on the date requested. Running two backup targets at once covers the operational side of that period.
Copying restore points back
When the cloud repository has to close by a certain date, or when years of retention would make the overlap too long, restore points are copied back. Three limits apply. Egress is charged on every gigabyte that leaves, and data in colder storage classes also incurs retrieval fees and may take hours to become readable. The transfer is bounded by the network link, so a large repository can take weeks. And the copy has to be made by the backup software, not by a generic file copy, so that the software's catalog knows where the restore points now live.
Estimating egress costs gives the arithmetic for pricing the transfer before committing to it.
Immutability locks follow their own clock
Objects stored under Object Lock in compliance mode cannot be deleted before the lock expires, by anyone. During a repatriation that means some cloud data remains, and is billed, until its lock runs out, even after it has been copied elsewhere. The closing date for the cloud repository is therefore set by the latest lock expiry, not by the end of the copy. It is worth listing lock expiry dates early, since they define the minimum length of the project.
The new repository needs its own immutability configured before the first backup lands, so that there is no period in which the newest restore points are unprotected.
Sizing the on-premises target
The new target has to hold more than the cloud repository's current size suggests. It receives new full backups at the start, any restore points copied back and normal growth from then on. If the cloud tier relied on a provider's deduplication or on a capacity tier that offloaded only older data, the on-premises footprint may differ from the cloud figure. Preserving older restore points during a migration explains how to decide which points are worth carrying over.
Keeping an off-site copy
Repatriation does not have to mean a single location. The 3-2-1 principle still asks for a copy somewhere else. That can be a second on-premises site, a colocation room or a much smaller cloud copy holding only the most recent or most critical restore points. The aim of repatriation is to choose where the bulk of the data sits, not to remove geographic separation.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It provides the S3 interface and Object Lock immutability that backup software already uses with cloud storage, so jobs can be pointed at it with the same repository type. In compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB, which allows the target to start at the size needed for new backups and expand as restore points are brought back. It is used as a target for Veeam and other backup software.
A sequence that works
A sound order of work is to install and lock down the new target, redirect new backups, run both repositories while short-term retention ages out, copy back only the long-term points that justify the egress, and close the cloud repository once the last lock has expired. Each step has a clear exit condition, and at no point is there a day without an immutable copy.