How Commvault Backup Works
To understand how commvault backup works, look at its three main parts. A central server coordinates agents that move data to storage targets. Teams set up this system to protect files, virtual machines, and databases. Admins often grant broad roles to help staff fix failed backup jobs fast. Those wide permissions let users run risky commands or read live production data. How commvault backup works across your servers The backup system uses three main tiers to copy and store data. First, a ce
Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To understand how commvault backup works, look at its three main parts. A central server coordinates agents that move data to storage targets. Teams set up this system to protect files, virtual machines, and databases. Admins often grant broad roles to help staff fix failed backup jobs fast. Those wide permissions let users run risky commands or read live production data.
How commvault backup works across your servers
The backup system uses three main tiers to copy and store data. First, a central control server holds the job schedules and system catalog. This brain tells every other component when to run and where data goes. It also tracks metadata so teams can find and restore old files later.
Second, lightweight agents sit on the production servers, virtual hosts, and database nodes. When a schedule triggers, the central server wakes the local agent up. The agent reads the changed blocks or files from the source host. It also compresses and deduplicates the data right on that source machine. This step shrinks the data before it ever crosses the local network.
Third, media servers receive the compressed streams from the local agents. These data movers write the blocks out to disk arrays, tape, or cloud buckets. They also maintain the deduplication database that tracks unique data blocks across jobs. When a team needs a restore, the flow runs in reverse order. The media server reads the storage blocks and sends them back to the agent.
How data movement and storage policies interact
Storage policies act as the traffic rules for every backup job. A policy defines where data lands first and how long it stays there. Teams set up primary copies on fast local disks for quick restores. Secondary copies then move older recovery points out to cheap cloud buckets.
The central database logs every block move and tracks retention dates. When a backup ages past its rule, the system marks those blocks free. Background jobs then prune the expired blocks from the disk or cloud targets. This lifecycle runs on its own once an admin sets the policy rules.
Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native backup roles solve and what they leave open
The backup platform includes built-in role-based permissions for users and groups. Admins can tie these roles to a directory service for single sign-on. You can give a junior operator rights to restart jobs for one team. You can also restrict who can delete backup copies or change retention rules. These controls do a good job of guarding the backup console itself.
Still, backup agents and database hosts still need direct admin maintenance. Engineers often log in to the underlying Linux, Windows, or database servers to fix issues. Native backup roles only decide who can log in to the backup software. They do not watch what commands an engineer runs on the database host. They also cannot inspect individual queries during a live restore check.
If an admin mounts a restored database to check a table, they see raw records. Static roles cannot rewrite sensitive fields like emails, phone numbers, or card numbers in flight. Teams also lack a single command log across SSH sessions and database queries. When an incident happens, auditors must stitch logs together from many different hosts.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What are the three core parts of a Commvault setup?
The architecture uses a central control server, data mover media servers, and client agents. The control server manages schedules, agents read source data, and media servers write to storage.
How does deduplication save network bandwidth during backups?
Source-side deduplication checks data blocks on the client server before sending them out. If the media server already holds a block, the agent skips sending it again.
Why do engineers still need direct access to backup and database hosts?
Console roles cover routine job restarts, but deep fixes require OS or database logins. Engineers log in directly to check disk mounts, agent logs, or restored database tables.