Database design for large amount of sensors at very fast intervals
150 new rows per second?  At least one of these needs to be true:


Using SSD, not HDD.
Batch loading (LOAD DATA, INSERT with multiple rows, etc)


Other notes:


Don't use DOUBLE.  Double takes 8 bytes and has far more precision than any sensor can provide.  This is important because the size of the data, as you noted, is important.  FLOAT gives you about 7 significant digits in 4 bytes, ample for virtually all sensors.  You could even consider DECIMAL or various *INT types, perhaps with scaling, to save even more space.
How much RAM do you have?  (I'll critique your my.ini settings after getting the RAM size.)
What is the problem with taking 2 hours to load 720 hour's worth of data?
What will you do with the data?  There are several directions I will point you, depending on what kinds of queries you will apply to the data.  Some will make a significant improvement in speed and/or space.


Back to your question:


  I've been tasked with designing a backup solution to store sensor data ... in the event that the primary transmission method of the sensors goes down.


If that is the question, the answer is trivial:  A flat file, in the same format as the raw data comes in.  That way, when recovering from the outage, you focus on getting data from a different source, but not a different format.