A backup repository is useful only if the team can recover the right data from it within an acceptable time. Storage capacity, successful job notifications, and a long retention period do not establish that on their own. The design must connect the backup process to a tested restoration procedure.
Offsite storage can separate a copy from the production environment, reducing dependence on one location or host. That separation needs to include access and operational planning as well as physical placement. If the same compromised account can remove production data and every backup, geography alone offers limited protection against that failure.
When assessing Unihost Storage Box for backup storage, verify the current protocol support, capacity, snapshot features, and recovery workflow against your backup software. The published service information lists file transfer options and backup related features, but these should not be assumed to provide immutable storage or an independent copy beyond the purchased service.
Ask application owners how much recent data they can afford to lose and how long the service can remain unavailable. These are the recovery point objective and recovery time objective. They should be stated for each important service rather than inherited from a generic infrastructure template.
A daily backup may be suitable for an infrequently changed reference site and unsuitable for a busy transaction system. Likewise, a restore that takes a day may be acceptable for an archive but not for a customer facing database. The backup schedule and storage design should follow these differences.
Define the recovery unit. It could be a file, a database, a complete application, or an entire server. The tools and validation steps needed for each are different. A system image may simplify host recovery while being inconvenient for restoring one accidentally deleted record.
Draw where production data, local recovery points, and offsite copies live. Include the accounts that can read or delete each copy. This often reveals dependencies that a simple count of backups hides.
A snapshot on the production storage can help with certain recovery tasks, but it shares important risks with that storage. Similarly, RAID can improve resilience to some drive failures without protecting against accidental deletion, corruption, or loss of the whole system. Keep these functions distinct in the design.
The Storage Box service description notes limits to protection against data loss and states that its data is not mirrored to other servers. Treat the repository as one component of a broader backup design, and confirm current contractual details before relying on a particular durability assumption.
Select the backup software first, then confirm that the repository supports the access method it requires. A mounted filesystem, an SSH based repository, and an object storage API are different interfaces. Do not assume they are interchangeable because each can hold files.
Verify version compatibility and operational requirements for the chosen tool. Check whether the account can run the required remote component, how authentication works, and whether the backup process needs special permissions. Test with a small dataset before scheduling a complete production transfer.
|
Design question |
Evidence required |
|
Can the tool write safely |
Completed test backup using the intended protocol |
|
Can it resume after interruption |
Documented and tested restart behavior |
|
Can the team recover credentials |
Approved access and key recovery procedure |
|
Can it restore the application |
Isolated restore with functional validation |
|
Can retention run safely |
Reviewed policy and a tested deletion process |
Avoid exposing unnecessary transfer services. Use encrypted access where supported and required, restrict credentials to their purpose, and review the repository permissions. The easiest connection method is not automatically the right one for sensitive production data.
The initial dataset is only the beginning of storage demand. Capacity also depends on change rate, backup method, compression, deduplication, and retention. Measure these effects with the actual data rather than relying on a universal savings percentage.
For illustration, a repository holding a 500 GB initial dataset and additional retained changes requires more than 500 GB of usable capacity. The exact requirement depends on whether unchanged blocks are reused and how old versions are removed. Keep the estimate transparent about these assumptions.
Leave room for temporary operations and growth. Some maintenance or compaction procedures need additional space, and a sudden increase in changed data can accelerate consumption. Define an alert threshold early enough to expand capacity or review retention safely.
Do not shorten retention automatically to hide a capacity problem. Retention reflects business and operational needs. Changes should be approved by the data owner and tested against recovery requirements, especially where discovering a problem may take days or weeks.
Encryption protects data only when the implementation and key handling match the threat being addressed. Transport encryption protects data while it moves. Repository encryption can protect stored content, but recovery still depends on access to the necessary keys and passphrases.
Keep recovery material outside the production host and within an approved secret management process. Test retrieval by an authorized backup operator. A key stored only on the server being protected can disappear in the same incident as the original data.
For teams using Borg, the Borg key management documentation describes key related operations. Follow the guidance for the deployed version and encryption mode. Document what must be retained and prove that it works in a restore; do not assume remembering a password is always sufficient.
Plan credential rotation and staff changes. The repository should remain recoverable when its original administrator is unavailable or leaves the company. At the same time, former staff should not retain access merely because the backup process was never updated.
Recovery time includes more than download time. The team must provision a destination, obtain credentials, retrieve data, restore it, and validate the application. Some steps can run in parallel, while others depend on earlier work.
For a rough lower bound, divide the data volume by an achievable sustained transfer rate. For example, transferring 500 GB at a sustained 100 MB per second takes about 5,000 seconds, or 83 minutes, before other work and overhead. These are decimal units and an illustrative calculation, not a promised service speed.
Test the actual path because bandwidth limits, file counts, latency, encryption, and destination disk performance can reduce throughput. A repository containing millions of small files may restore differently from one large archive with the same total size.
If the measured recovery time misses the objective, change the design. Options may include a closer recovery copy, a different backup format, more suitable transfer capacity, or a prepared recovery environment. Do not solve the problem only by changing the number in the plan.
Schedule tests that cover different recovery cases. A sample file restore checks one capability; an application restore checks many more. Rotate through important services and include a scenario where the production host is unavailable.
Record the following for each exercise:
- Backup identifier and the data point it represents.
- Operator and credentials used through the approved process.
- Destination environment and its isolation controls.
- Start time, completion time, and manual interventions.
- Data integrity and application checks performed.
- Problems found and the person responsible for fixing them.
Use a safe destination so restored scheduled tasks do not send real messages, process payments, or overwrite production data. Restore testing should prove recoverability without creating a second uncontrolled production environment.
Test selective restoration as well as full recovery. Accidental deletion may require one directory or one application object rather than an entire server rebuild. Confirm how the backup tool identifies the correct version and how the operator avoids overwriting newer valid data. Some applications need a temporary restored database to extract the required records safely. Document that route before the request arrives, because a technically complete backup can still be cumbersome to use when the business needs a small, precisely defined part of its history returned quickly.
A successful job can protect the wrong directory or omit a newly added database. Review backup scope after application changes and compare it with the recovery inventory. Monitor the age of the latest usable backup, transferred volume, and unexpected changes in duration.
Send alerts to an accountable owner and test that route. Investigate repeated failures promptly, but also examine suspiciously small successful backups. Both can indicate that the protection the team expects is no longer being delivered.
An offsite repository becomes dependable through these operating practices. Storage is the destination; recoverability is the outcome. A design that documents copies, permissions, keys, retention, and tested restoration gives the business evidence that its data can be used again when production is unavailable.