A small software company with approximately 30 employees operated several production and internal services on a mix of dedicated servers and virtual machines.<\/span><\/p>\n The infrastructure included:<\/span><\/p>\n The company had backups, but there was no consistent backup architecture.<\/span><\/p>\n 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.<\/span><\/p>\n The existing process had three major weaknesses:<\/span><\/p>\n The company was looking for small business backup solutions that would not require building a dedicated internal backup team.<\/span><\/p>\n The goal was not simply to \u201cmake more backups.\u201d<\/span><\/p>\n The backup architecture needed to provide:<\/span><\/p>\n For critical databases, the target recovery point was approximately one hour. For application files and virtual machines, a daily recovery point was sufficient.<\/span><\/p>\n The support team first mapped the systems that actually required protection. This avoided treating every terabyte of data as equally critical.<\/span><\/p>\n Data was divided into three groups:<\/span><\/p>\n <\/p>\n A separate backup environment was introduced instead of storing backups on production disks.<\/span><\/p>\n The resulting model was: Production servers – local snapshots \/ database dumps – encrypted backup transfer – Dedicated backup storage – retention and integrity verification.<\/span><\/p>\n 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.<\/span><\/p>\n <\/p>\n 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.<\/span><\/p>\n <\/p>\n Backup data was encrypted before or during transfer.<\/span><\/p>\n Retention rules were configured so that the company kept:<\/span><\/p>\n Old backups were automatically removed according to policy rather than manually deleted when storage became full.<\/span><\/p>\n <\/p>\n Backup completion was added to the monitoring process. A backup job was no longer considered successful simply because a scheduled script had started.<\/span><\/p>\n The team checked:<\/span><\/p>\n This meant that a silent backup failure could be detected before a recovery was actually needed.<\/span><\/p>\n <\/p>\n 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.<\/span><\/p>\n Servers: Dedicated Server + Backup Server \/ Backup Storage<\/span><\/p>\n Services used:<\/span><\/p>\n 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.<\/span><\/p>\n The most important improvement was not storage capacity. It was recoverability.<\/span><\/p>\n The company could now answer three questions that had previously been unclear:<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n The next planned step is an additional geographically separated recovery copy for the most business-critical datasets.<\/span><\/p>\n Results at a glance<\/b>: 1-hour database RPO, automated offsite backups, monitored backup jobs, tested recovery procedure, less manual administration.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":7,"featured_media":9169,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49],"tags":[],"class_list":["post-9168","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-study","has-post-title","has-post-date","has-post-category","has-post-tag","has-post-comment","has-post-author",""],"yoast_head":"\n\n
Initial situation<\/b><\/h2>\n
\n
Technical challenge<\/b><\/h2>\n
\n
What the Unihost team did<\/b><\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Unihost solution used<\/b><\/h2>\n
\n
Technical result<\/b><\/h2>\n
\n
Business impact<\/b><\/h2>\n
What’s next<\/b><\/h2>\n