Every backup comparison has rows for capacity, support and maintenance, and none for the person who runs it. In a team of three or four generalists that omission is larger than most line items above it, because hours spent on backup are hours not spent on the network, the virtualization stack or the help desk. The work is real, recurring, and almost never written down anywhere it can be compared.
The reason it stays invisible is not carelessness. Backup administration arrives in fragments: ten minutes checking a report, a job rerun before lunch, an afternoon lost to a failing agent, a week of evenings during an upgrade. No fragment is large enough to log, and together they can exceed the difference between two quotes that took weeks to argue over.
The answer is not a time and motion study. It is a rough measurement, taken honestly over a few weeks, expressed in hours rather than money, and placed beside the purchase decision with its limits stated.
Where the hours actually go
The first category is job babysitting. Somebody opens the console each morning, reads the overnight results, reruns what failed, and decides whether a partial success matters. On a good week that is a short routine. It is also a daily interruption that never disappears, and it scales with job count, not data volume.
The second is failure triage, the expensive one because it is unbounded. A job fails, and the cause could be a snapshot that would not release, a credential rotated by somebody else, a full volume, a network path, an agent stopped by a patch, or the target refusing writes. Each lives with a different team or system, and the time goes into working out which rather than fixing it.
The third is capacity firefighting: free space falling faster than expected, a decision about what to shorten, a conversation about money nobody budgeted this year. That work is predictable in kind, and much of it is avoidable through capacity alerting that fires early enough to be acted on rather than once jobs are already failing.
The tasks that never reach the comparison sheet
Alongside the daily routine sit the periodic tasks, the ones missing from every evaluation. They are easy to forget because they happen a few times a year, often enough to consume real time and rarely enough to feel like part of the job.
| Activity | What triggers it | How to capture the time honestly |
|---|---|---|
| Daily job review and reruns | The overnight schedule, every working day | Time the routine on five ordinary mornings, including the reruns |
| Failure triage | A failed or partial job with an unclear cause | Note start and stop times per incident for a month, including waits on other teams |
| Restore requests from users | A deleted file, a mailbox item, a rolled back change | Count requests per month and time a typical one end to end |
| Patching, upgrades and certificate renewal | Vendor releases, expiry dates, advisories | Log the whole window: planning, approval, execution, verification |
| Audit and insurance evidence | An annual questionnaire or auditor request | Record hours from last year's cycle, including chasing screenshots |
| The annual restore test | Policy, or the one week nobody can postpone it | Total hours across everyone involved, not just the person running it |
The last two rows behave differently. Audit evidence and the annual test are driven by dates rather than events, which makes them schedulable, and both tend to be absorbed by whoever is least busy. A test that produces a written result costs more hours than one that does not, which is a reason to plan it rather than avoid it, and deciding in advance how much to test and what to measure keeps that cost bounded.
Measuring it honestly for a few weeks
A usable measurement needs less rigor than people expect and more consistency than they usually manage. Four weeks covers a weekend of maintenance and one awkward failure. A shared note with three columns, date, activity, minutes, collects it without ceremony, and everyone who touches backup writes in the same one.
Two rules keep the data meaningful. Record attended waiting as work: a rerun that has to be watched occupies the person even though nothing is typed. Record interruption cost separately from task time, since a ten minute job check arriving mid firewall change costs more than ten minutes.
Then add the periodic tasks from tickets and memory rather than waiting a year to observe them. Last year's upgrade, the most recent audit cycle and the last restore test all left traces in a ticket system or calendar, and a reasonable reconstruction beats leaving them out entirely.
Putting hours beside a purchase without false precision
The temptation is to convert hours into a currency figure and put it in the comparison. That is where these exercises lose credibility, because the loaded hourly rate is an argument in itself and any number derived from it inherits the argument.
Hours are the safer unit. Two platforms can be compared on estimated administrative hours per month and on how much of that load is fixed rather than proportional to the estate. The question that follows is answerable: which measured activities does each option remove, reduce, or move elsewhere. A platform that removes a weekly maintenance task removes a known quantity of hours. One that adds a console to patch adds them.
Where the measurement justifies money is at the boundary, and only in ranges. If the recorded load approaches a full working day each week across the team, the comparison is no longer between two products, it is between a product and the capacity to do other work. Stating that as a range, with the measurement period and method attached, is honest. A precise annual figure is not.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, running on infrastructure the customer already operates, at scales from roughly 50 TB to 8.5 PB. Its relevance here is narrow and worth stating plainly: it affects the storage target part of the load, not the backup software part. Daily job review, restore requests and most failure triage stay where they are.
The parts it does touch are the ones a small team under counts. A backup target has to be patched, its certificates renewed, its capacity watched, and its behavior understood well enough to explain to an auditor. Those tasks exist on any target, and their cost differs mostly with how much specialist knowledge each demands. An S3 compatible target the backup software addresses directly, with immutability set through S3 Object Lock, keeps retention configuration in the backup console rather than spread across two systems, which is one fewer place to check.
Two further items belong in the same column. Platform maintenance is recurring work with its own window, and sequencing storage maintenance against the job schedule decides whether it happens during working hours. Growth handled by adding capacity to a running system is different work from a migration, and that difference shows up in hours rather than purchase price.
What to write down and when
Run the four week log once a year, in an ordinary month rather than a quiet one, keeping the same three columns so results stay comparable. The value is not the total but the movement: a load that has grown since last year is evidence of something, usually more jobs, more agents or more manual workarounds accumulating around a platform nobody has time to revisit.
Keep a standing list of the periodic tasks with the hours each consumed most recently, updated as they happen rather than reconstructed later. That list ages best, and it is the most useful part in a budget conversation, since it describes work already done rather than predicted.
Before a purchase decision, write the current measured load at the top of the evaluation and record, for each option, which activities it changes and by roughly how much. Keep the assumptions in the same document, including the measurement period. The outcome is not a precise cost. It is a decision made with the largest hidden line item visible, which is the most any small team can honestly claim. The same discipline applies to what the on call runbook assumes about who is available, since both questions come back to the same finite set of hours.