Project profile
A small software company with approximately 30 employees operated several production and internal services on a mix of dedicated servers and virtual machines.
The infrastructure included:
- customer-facing applications;
- PostgreSQL databases;
- internal file storage;
- a CRM system;
- several development VMs;
- approximately 4 TB of active business data.
The company had backups, but there was no consistent backup architecture.
Initial situation
Different systems were backed up in different ways. Some application directories were copied manually to another disk. Database dumps were created by cron jobs. Several virtual machines were backed up irregularly, and part of the data was synchronized to third-party cloud storage. There was no central retention policy and, more importantly, restore procedures were rarely tested.
The existing process had three major weaknesses:
- backups were stored too close to production;
- failures could remain unnoticed for several days;
- recovery depended heavily on one administrator knowing where everything was stored.
The company was looking for small business backup solutions that would not require building a dedicated internal backup team.
Technical challenge
The goal was not simply to “make more backups.”
The backup architecture needed to provide:
- separate production and backup storage;
- encrypted transfer;
- automated backup schedules;
- different retention periods for databases and files;
- monitoring of failed backup jobs;
- regular restore testing;
- protection against accidental deletion;
- predictable storage capacity.
For critical databases, the target recovery point was approximately one hour. For application files and virtual machines, a daily recovery point was sufficient.
What the Unihost team did
- Infrastructure and data audit
The support team first mapped the systems that actually required protection. This avoided treating every terabyte of data as equally critical.
Data was divided into three groups:
- Databases: frequent backups and short recovery points;
- Application servers and VMs: daily incremental backups;
- Archives and static files: longer retention with less frequent backup cycles.
- Designed the backup architecture
A separate backup environment was introduced instead of storing backups on production disks.
The resulting model was: Production servers – local snapshots / database dumps – encrypted backup transfer – Dedicated backup storage – retention and integrity verification.
For selected workloads, an additional offsite copy was retained separately from the primary environment. This created a practical version of the 3-2-1 backup principle without adding unnecessary infrastructure.
- Automated backup jobs
The support team configured automated jobs using appropriate tools for each workload. Database backups were created independently from filesystem backups so that application recovery did not depend on one large server image. Incremental backups were used to reduce transfer volume and storage consumption. Backup jobs were scheduled during lower-load periods and staggered to prevent multiple servers from saturating the network simultaneously.
- Added encryption and retention policies
Backup data was encrypted before or during transfer.
Retention rules were configured so that the company kept:
- frequent recent database copies;
- daily restore points;
- weekly recovery points;
- longer-term monthly archives.
Old backups were automatically removed according to policy rather than manually deleted when storage became full.
- Configured monitoring
Backup completion was added to the monitoring process. A backup job was no longer considered successful simply because a scheduled script had started.
The team checked:
- exit status;
- backup age;
- storage availability;
- free storage capacity;
- failed transfers.
This meant that a silent backup failure could be detected before a recovery was actually needed.
- Tested recovery
Finally, selected files, a database, and a virtual machine were restored into an isolated environment. The restore test identified several small issues in application configuration that would otherwise only have appeared during a real incident.
Unihost solution used
Servers: Dedicated Server + Backup Server / Backup Storage
Services used:
- backup architecture design;
- backup server setup;
- encrypted data transfer;
- automated backup configuration;
- retention configuration;
- monitoring;
- restore testing;
- ongoing server administration.
Unihost currently offers dedicated backup servers, Proxmox Backup Server deployment and managed backup assistance, as well as external backup storage accessible through tools such as Restic, BorgBackup, Rclone and rsync.
Technical result
The most important improvement was not storage capacity. It was recoverability.
The company could now answer three questions that had previously been unclear:
- What data is backed up?
- How old is the newest valid backup?
- How long will it take to restore the service?
A test restoration of a production database that previously required more than two hours was completed in approximately 35 minutes after the new process was implemented.
Business impact
The internal IT team no longer needed to manually check dozens of backup jobs. Infrastructure recovery also became less dependent on individual employees. The company gained a documented server backup solution for small business workloads without building a separate backup platform internally.
What’s next
The next planned step is an additional geographically separated recovery copy for the most business-critical datasets.
Results at a glance: 1-hour database RPO, automated offsite backups, monitored backup jobs, tested recovery procedure, less manual administration.