First, you need to predict that you'll need to backup software. Typically
people back up their data, as software can be reinstalled (until it can't,
because package retention policies). Then you need to ensure you either have
enough backup space or don't store 30 copies of the same thing, one for each
server (it quite often happens that OS and software weigh much more than data
they host).
Second, restoring from backup limits how you can rebuild a server to just one
rigid way. You can't bring another already running server to what you have
elsewhere.
Sorry, I assumed you were talking about rebuilding a local mirror repository that you use to provide software for your other hosts. That would just be one backup of the packages and meta data that you can restore. Is there a reason you can't mirror the packages and repositories you use?
Just mirroring doesn't change the retention policy (unless the term has
changed its meaning in recent fifteen years), so it won't do. But this is
moves the discussion to spoken language semantics, which I don't feel like
pushing too far.
My point with the packages is that you need your own copy that you have
control over, so they don't disappear unexpectedly. Pulling already-built
packages from some other repository would be fine from this standpoint, though
I prefer rebuilding them myself and keeping along with source packages.
Second, restoring from backup limits how you can rebuild a server to just one rigid way. You can't bring another already running server to what you have elsewhere.