Many of the db and repo volumes are magnetic ("standard"), not SSD ("gp2").
There is no reason for these volumes to be magnetic, and magnetic volumes are undesirable. Their pricing and I/O characteristics aren't directly comparable to SSD, but generally they have less I/O, less flexible I/O, and aren't meaningfully cheaper.
We should swap these to become SSD volumes. (Compacting the tier may moot some of this by reducing the number of devices; we can migrate away from magnetic devices.)
I'm going to go through the volumes type-by-type instead of host-by-host, starting with the backup volumes (because those should be fine to detach as long as the backup isn't running). It looks like backups run daily at 2300, so that should give me plenty of time.
Backups should run continuously (starting 12 hours after the instance launches, then every 24 hours after that):
However, they'll retry if they fail, so this should be safe.
Since I imagine we'll just rebuild everything "fairly soon" to rebalance/compact/NAT and you can't use this strategy for non-bak volumes I'm not sure it's worth doing by hand, though.
I think all the T13076 stuff is blocked on me for now unless you're feeling especially ambitious about trying to get bin/host download working on 2GB+ files (T12907 / D19011). That might be a bit of a mess of a task though since I think I have a lot of secret cURL knowledge from over the years that is only somewhat-documented in HTTPSFuture.