A backup storage handover happens whenever responsibility for the repository passes to someone new: a colleague leaves, a team is reorganized or a managed service contract ends. The system keeps running, which hides how much of its safe operation lived in one person's head. Passwords, retention decisions, the reason a certain job is configured oddly and the steps for a restore under pressure are rarely written down. The new administrator inherits a working system and an incomplete picture of it.
This post is a guide for the person taking over, and a checklist for the person handing over, so that nothing critical is lost in between.
Backup storage is a quiet system when it works. It is touched rarely, so knowledge about it is concentrated and seldom shared. The risks at handover are specific. Credentials known to one person leave with them. Encryption passwords stored only in someone's memory make backups unreadable. Immutability and retention settings whose reasoning is forgotten get changed by a well-meaning successor. And the first real restore becomes the new administrator's first attempt at one.
| Area | What the new administrator needs | Risk if it is missing |
|---|---|---|
| Access | Named accounts on the backup server, repository and hardware management | Shared or departed accounts remain the only way in |
| Secrets | Location of encryption passwords, access keys and break-glass credentials | Backups cannot be decrypted or reached in an emergency |
| Architecture | Diagram of sources, proxies, repositories, sites and network paths | Changes break dependencies nobody knew about |
| Policy | Retention tiers, immutability periods and the reasons for them | Settings altered without understanding the consequences |
| Operations | Monitoring, alert destinations, routine checks, patch schedule | Alerts go to a mailbox nobody reads |
| Recovery | Runbooks, restore test history, measured restore times | First restore under pressure is improvised |
| Commercial | Licenses, support contracts, renewal dates, vendor contacts | Support lapses unnoticed, renewals missed |
| Capacity | Current usage, growth trend, planned expansions | Repository fills with no order placed |
The most urgent items are the ones that cannot be reconstructed. An encryption password that is lost cannot be recovered by the vendor. The outgoing administrator should show where each secret is stored, and the incoming one should confirm they can retrieve it. After the handover, shared passwords are changed, the departing person's accounts are disabled and access keys they could have copied are rotated. Who holds the recovery copy of the backup encryption keys covers how those secrets should be kept so that they survive staff changes.
The new administrator should receive individual accounts, with multi-factor authentication, on every interface. Inheriting a predecessor's login hides who did what in the audit trail from that day on.
Every backup environment has settings that look wrong and are deliberate: a job that runs at an odd hour to avoid a batch process, a retention period set by a regulator, an immutability window chosen to match the insurer's requirement. A new administrator should spend the first weeks observing and asking why, and make no changes to retention or immutability until the reasoning is clear. Where the predecessor is still reachable, an hour walking through each job and repository is worth more than any document.
If the reasoning cannot be recovered, the policy should be re-derived from requirements. Matching retention to recovery needs gives a way to do that.
Nothing builds an accurate picture faster than a restore. In the first month the new administrator should restore one file, one whole virtual machine to an isolated network and, if there is a second site, one system from the second copy alone. Each test confirms that credentials work, that the documentation matches reality and how long recovery takes. Gaps found here are found on a quiet day. Choosing representative workloads for restore tests helps decide what to restore.
The results go into the runbook. Recovery runbooks for on-call staff describes what that document should contain so that a third person could follow it.
Alert routing is easy to overlook. Backup software and storage systems are often configured to notify the person who installed them. When that person leaves, failed jobs, full repositories and hardware faults are reported faithfully to an inactive mailbox. Every notification target should be checked and pointed at a team address or ticket queue, and a test alert sent from each system to prove it arrives.
A good handover takes a few days of preparation. Write down the eight areas in the table, each on a page or less. Walk the successor through one backup job from source to repository. Perform one restore together. Transfer vendor and support contacts by introducing the new administrator directly. And agree a date after which the outgoing accounts are disabled, so that the cut-over is deliberate.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Its capacity, health and alerts are visible in one management interface, which gives a new administrator a single place to learn the state of the repository. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires, so restore points already written stay protected through a change of staff.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
A reasonable plan for a new backup administrator has three stages. In the first two weeks, secure access and secrets and confirm alerts arrive. In the first month, restore something from each tier and each site. By the end of three months, review capacity, contracts and policy and write down what was learned. After that, the system has an owner who knows it from experience, and the next handover will start from a far better record.