Commvault Firewall
You set up a commvault firewall by creating network topologies that define how backup nodes talk. These rules control port routes, tunnel directions, and encryption between your server and client hosts. Most teams start by opening broad port ranges to get backups running fast. Broad network rules and shared admin roles leave your backup servers open to risky commands. How a commvault firewall topology works Backup tools must reach many servers across different network zones. Some hosts sit in
Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a commvault firewall by creating network topologies that define how backup nodes talk. These rules control port routes, tunnel directions, and encryption between your server and client hosts. Most teams start by opening broad port ranges to get backups running fast. Broad network rules and shared admin roles leave your backup servers open to risky commands.
How a commvault firewall topology works
Backup tools must reach many servers across different network zones. Some hosts sit in private subnets behind strict packet filters. Other hosts run in public cloud regions or remote branch offices. The built-in network rules group these machines into clear client groups. You then apply a topology to link those groups together.
A topology tells each host how to open a path. In a one-way setup, only one side can start the network call. You might let the central server call out to a client in a restricted zone. Or you can make the isolated client call back to the central server. Once the first call succeeds, both sides send backup data over that single tunnel.
Teams also set up dedicated relay nodes in complex networks. These intermediate nodes sit in a shared zone and pass traffic between closed subnets. This design keeps your main backup server off the public network. You can also turn on data encryption and certificate checks for every tunnel. When you push the topology, the central server sends the rules to all group members.
Where native network rules fall short for admins
Native network topologies solve machine-to-machine routing for scheduled backup jobs. They keep backup agents talking across strict perimeter firewalls without opening dozens of ports. They also helps keep raw backup streams stay encrypted as they cross untrusted networks. For automated daemon traffic, this built-in design works well.
The gap appears when human engineers log in to fix or check the system. Admins often need direct shell or database sessions on the backup hosts. They log in to check failed jobs, tune storage pools, or query the main database. A network topology only checks if an IP address and port can link up. It does not check what a human user runs once the session starts.
Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When an engineer opens a session, they often use a shared admin role. That role lets them run any shell command or database query on the host. A single bad query can wipe out job records or expose sensitive data. If a result set includes emails, phone numbers, or card numbers, the terminal prints them in plain text. Masking rewrites matched fields in results, which native port filters cannot do.
Managing human sessions alongside backup network rules
To keep backup systems safe, teams must separate daemon traffic from human maintenance work. Keep using native topologies for agent traffic between your media servers and client nodes. Lock down those routes so only the backup processes can use the assigned ports. Never reuse those broad network openings for daily admin logins or ad-hoc database checks.
For engineer logins, move away from static keys and broad network tunnels. Require every user to log in with their own identity before running a command. Check each command or query in flight rather than trusting the whole network link. Apply data masking to rewrite national IDs, emails, and card numbers in query outputs. This keeps your backup servers safe from both network threats and human mistakes.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does a one-way network rule do in a backup setup?
A one-way rule lets only one side start the network call across a perimeter filter. Once that call links up, both hosts send backup data through the open tunnel.
Why should teams group hosts before building firewall rules?
Client groups let you apply one routing rule to many servers at the same time. When you add a new server to the group, it gets the network rules right away.
Do port rules protect the backup database from bad admin queries?
No, port and IP rules only decide which machines can reach the server port. They do not inspect SQL queries, block destructive commands, or mask emails and card numbers in results.