Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
In general, it's often easy to prioritize egress traffic as you desire. Ingress traffic control is much more difficult to manage (ideally you manage ingress on the other side of the link's egress).
For example, for ingress you could rate limit non-server traffic but that doesn't always guarantee non-server traffic won't fill your ingress capacity, and even when it does, it's not dynamic (i.e. non-server traffic won't obtain bandwidth not being used by the server).
For best ingress traffic management, a 3rd party traffic shaping device would be the best option, but again, even they can't deal with every situation.
Assuming your 800 WAN connection is some inexpensive DSL/CABLE connection, assuming you cannot control other side's egress, the least expensive option might be to obtain another DSL/CABLE connection, i.e. one for users and one for the server. As 800 series often have a special WAN port, you might need another or you might upgrade to a higher level ISR that can manage two WAN ports equally.
