The Problem: Backups Are Not Just an IT Task
Backups are easy to ignore when everything is working. But in a real company environment, data loss does not need to come from a major disaster. Sometimes it is just a failing disk, a user accidentally deleting a folder, or a workstation that needs to be formatted without warning.
In the environment I manage, we had already faced problems like that. User files being lost, shared folders needing better protection, and the most critical risk was our on-premises ERP database. This database stored essential business information, and at the time, we did not have a proper backup/rollback strategy if something serious happened to the server.
That situation forced me to think beyond simple file copies. I needed to design a backup strategy that considered different types of data, different failure scenarios, and different recovery needs.
This post is the first part of a series where I will explain how I started building a layered backup strategy for our environment.
The Environment I Was Working With
The company environment was mostly on-premises, with Active Directory, Windows workstations, file shares, Proxmox virtual machines, and an ERP system backed by a PostgreSQL database running on a Linux VM. At the time, we did not yet have a mature cloud-based endpoint or backup structure, so I had to work with the tools and infrastructure already available.
The Risks I Needed to Address
Before choosing tools, I tried to separate the risks into different categories:
- users losing their local files (happens more than you think);
- shared folders and files being accidentally modified or deleted;
- VM failure;
- ERP database corruption or loss;
- loss of the primary backup destination;
- physical disaster or ransomware affecting the local environment.
The Layered Backup Strategy
User File Protection
For user files, I implemented a policy-based (GPO) approach using Active Directory and Folder Redirection. The goal was to keep important user files synchronized with a server location, reducing the risk of data loss when a workstation failed or needed to be formatted.
Shared Folder Backups
Shared folders had a different risk profile. They were used by multiple departments and users and contained files that could be accidentally deleted, overwritten, or modified. For this reason, they needed scheduled backups and a clear restore path.
PostgreSQL Database Backups
The ERP database required a different approach. A database is not just another folder to copy. Because it was running on PostgreSQL, I chose to implement a database-aware backup strategy with Barman, allowing more reliable backup and recovery planning than a simple file copy.
The goal was not only to have a copy of the database files, but to have a recovery process that respected how PostgreSQL works. This matters because databases can be in an inconsistent state if they are copied incorrectly while running.
Proxmox VM Backups
VM backups were used to protect the infrastructure layer. While database-level backups protect the data inside the system, VM backups help recover the server state, operating system, services, and configuration. This layer was important because local backups are still exposed to local incidents. If the same physical site, network, or administrative environment is compromised, a remote copy becomes part of the recovery plan.
Secondary Local Backup Layer
I also wanted to avoid depending on a single backup destination. If all backups exist only in one place, that storage becomes another single point of failure. For that reason, I added a secondary local backup layer on a dedicated server.
Remote Backup Layer
Finally, I added a remote backup layer. Local backups are useful for fast restores, but they do not fully protect against physical incidents, major infrastructure failure, or scenarios where the local environment itself is compromised.
Turning the Strategy Into Backup Routines
After defining the main risks, I translated the strategy into scheduled backup routines. Each routine had a specific purpose, frequency, retention period, and recovery expectation. This helped avoid treating all data the same way, because user files, shared folders, virtual machines, and databases have different recovery needs.
| Backup area | Purpose | Frequency | Retention | Notes |
|---|---|---|---|---|
| Shared folders | Protect department and business files from deletion, overwrite, or corruption | Daily | Daily and weekly retention | Incremental backup to reduce storage usage |
| PostgreSQL ERP database | Protect critical business data with database-aware recovery | Daily full backup + frequent WAL archiving | Short-term operational retention | Restore tested regularly |
| Proxmox VMs | Recover server state, OS, services, and configurations | Daily | Several recent recovery points | Different backup modes depending on VM criticality |
| User folders | Reduce data loss during workstation failure or formatting | Continuous/synchronized | Based on server-side backup policy | Implemented through Active Directory and Folder Redirection |
| Secondary local backup | Avoid depending on only one backup destination | Daily / scheduled | Depends on source backup type | Dedicated local backup server |
| Remote backup | Add protection against local infrastructure failure | Scheduled | Depends on available storage and recovery needs | Used as an offsite recovery layer |
What I Learned
One of the main lessons I learned is that backup strategy is not only about creating copies. It is about understanding what can fail, how much data the company can afford to lose, how fast systems need to be restored, and whether the recovery process actually works when tested.
What Comes Next
This post is only the overview of the backup logic I built. In the next articles, I will break down each layer in more detail, including how I used Group Policy Folder Redirection for user files, how I configured PostgreSQL backups with Barman, how Proxmox VM backups fit into the strategy, and how I added secondary local and remote backup layers.