How to Set Up Policy Routing for Separate Backup and User Traffic

Separate backup traffic with an explicit source address or packet mark, a dedicated routing table, and a narrowly scoped rule. Do not replace the main default route or assume that interface metrics can classify two workloads from the same host.

This design is useful when interactive users need the fast or low-latency uplink while scheduled backups use a secondary gateway. The risk is asymmetric routing: replies leave through a different interface than the request, causing stateful firewalls or remote peers to reject the session. Keep console access, record the original rules, and build the alternate path before directing traffic into it.

Choose a classifier that stays stable

Use a dedicated source IP when the backup service can bind to one address. It is easier to inspect and survives service restarts better than rules based on changing destination addresses.

If both workloads share one address, classify backup connections with a firewall mark and preserve that mark for the connection. Linux policy routing evaluates rules before consulting the selected table; the routing policy database is therefore the decision layer, while each table holds routes.

Do not classify solely by a cloud provider's IP range unless you control and maintain that list. If no stable source, destination, port, user, or namespace identifies the backup flow, stop and separate the workload at the container or network-interface level first.

Build the backup table before adding its rule

Create a named table containing the connected subnet route and the backup gateway's default route. Without the connected route, the gateway itself may be unreachable even though the default entry looks correct.

Query the proposed decision with a route lookup that supplies the same source address or mark the service will use. A result showing the backup interface and expected source is a pass; a lookup falling back to the main table means the classifier or priority is wrong.

Add the narrow rule at a priority that precedes the generic main-table rule but does not override local routes. Keep an explicit rollback command in the same terminal session and never test first over the path you are changing.

Preserve reply symmetry and local access

Confirm that the upstream router knows how to return traffic to the selected source network, or apply source NAT only at the correct egress boundary. A policy rule can choose an outbound route, but it cannot make a remote gateway understand an unknown private subnet.

Check reverse-path filtering when valid replies arrive on an interface Linux would not select under the main table. Use a mode appropriate to the multihomed design rather than disabling validation globally, and verify the choice with packet captures on both interfaces.

Keep management, DNS, and LAN traffic in the main table unless separation requires otherwise. The ZimaSpace guide on reliable network-share use is a useful companion when the routed backup also depends on a mounted storage path.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Test failure as well as success

Start one interactive transfer and one backup, then inspect interface counters and connection state. The backup bytes should rise only on the backup egress while the user session remains on the primary path.

Temporarily block or disconnect the backup gateway during a controlled window. If the design is fail-closed, the backup should stop without migrating silently to the user link; if failover is intended, document that behavior and cap its bandwidth.

Reboot once and repeat the original concurrent workload so rule order and marks are proven persistent. Stop when lookups, packet captures, and application logs agree; roll back if management access changes, replies become asymmetric, or unrelated traffic enters the backup table.