Hi,
FabricPath allows the creation of layer-2 topologies that we might not have considered when building networks reliant on spanning tree, so this is certainly a valid design.
While it's certainly a valid option the main reason I personally don't like this type of design is that the capacity to the backup network is only used for backup traffic, which typically runs for a short period of time outside of business hours. This means for the majority of time the capacity that provisioned for the backup network goes unused.
I prefer the approach where the entire provisioned capacity is made available for both data and backup traffic, but with an appropriate QoS policy to provide protection. You can do this by configuring a QoS policy that limits backup traffic to a minimum percentage of bandwidth in the event of congestion.
If the backup is run out of business hours then, assuming a minimal amount of business related traffic at that time, the backup traffic is able utilise close to the entire link capacity. If for some reason a backup is started during business hours or continues into the start of the business day, then that traffic is only able to utilise a percentage of the entire bandwidth.
We've used this approach in our network for many years, with both GE and now 10GE connected servers, and have not experienced any problems. This has allowed us to realise some significant cost savings as we no longer have to purchase hardware specifically for a backup network.
I'm sure it's not an approach that would work in all environments, but it has for us.
If you want to maintain total separation of the production and backup traffic using the approach you've outlined, then one point to consider is the capacity of your FabricPath backup network. If the number of links between your leaf switches and the switches hosting the media servers is the same as that between the leaf and spine switches, you would need to ensure that the backup network were not used for east-west production traffic.
Regards
