For CSGO it's about 80MB/hour at 32Hz (apparently the current OW rate). Many servers run at 128Hz.

Logging a rolling week's activity at that higher rate requires 53GB but you could dramatically reduce the burden by only keeping things with in-game reports and then deleting recordings after the last issue was dealt with.

My point is it's not nothing, but it's nothing by modern standards if you've got more than two brain cells to rub together.

At that rate there's also going to be plenty of redundant information, so I think this data would compress quite well.

Then something is wrong with the logging.

If you only record player input: mouse movement, clicks and keystrokes, it should be much lower.

It's probably recording what amounts to a demo record, which basically contains everything you would need to reconstruct the player's point of view as if you were spectating them. This means the record must contain everything the server sends to that player (other players' locations, sounds, map state changes, chat, etc.).

Technically you could record only the players' inputs but to play back such a recording, you would then have to deterministically reconstruct the entire match from all players' inputs. That's a bit more complicated than just replaying the local part of the simulation that your client already does with what data the server sends to players during normal course of gameplay.

oliwarner's numbers amount to about 45 bytes per frame per player, which is not unreasonable.

Should it? What sort of density do you expect? 32 ticks a second, say 16 players. At least 512 state/event points to log per second, plus running game state/events.

As I said, it's not nothing, but it's not bad.

Except that the data logged isn't just "mouse moved x,y to x,y" but more like 'hid frame was X'. And empty hid frames are still hid frames.

you can inspect it yourself, I assume the format is the demo record which has been available in source games since decades