Happy New Year right back at ya’. I’d be inclined to split it in two: have a LAN connected acquisition unit and then use a real computer with a real filesystem to receive the datastream and store it, process it, graph it, archive/delete old log files etc. etc.
@Robert.Wall’s numbers are probably as good a place to start as any: 2 × 30 samples × 60 per second per channel. That’s 21,600 samples per second, or 345.6 kbits/sec (even less if you pack two 12-bit readings into 3 bytes, although I doubt that’s necessary). I reckon an stm32f207 could easily act as 6-channel LAN connected ADC, and just spew the readings out over UDP, maybe throw a msec timestamp in with each batch so you can detect lost packets.
Since you’re not trying to calculate real power you can probably tolerate phase errors, but if not, the time offset of each reading within a message would be well defined - it would reflect the ADC conversion time, so if you were really keen you could potentially reconstruct the exact timing of each sample on the “mainframe” (with further adjustments needed to compensate for any sensor induced phase shift).
You could even have multiple acquisition units spread around the campus and one “mainframe” siphoning all the data off them. I think the stm code would only be a few lines of C - I might even knock up a proof-of-concept implementation next time the rain drives me home from the beach. The real work would then all need to be coded on the “mainframe”.