Given your design constraints, you really can't (easily) compress your data much further. If sometimes your data will consist of the same number again and again, you could use run-length encoding... but I doubt it is going to be worth your trouble.
The "use 9 bytes of storage for each 8 data" answer, given above, really is the best you can do, given what you explained as your needs.
If the data is critical, and you can't ensure that power will never be interrupted, you are faced with another problem:
Suppose you've collected 6 data, and written the first 8 bits of each to your EEPROM, saving the 9th bit of each for writing in a moment... and then the power fails.
When the power returns, assuming the device fires up happily, and collects, say, 16 more data, those new 16 data will write nicely to the next 18 bytes in the EEPROM.... assuming, by the way, that you've solved the problem of "where do I continue writing after a power failure" problem.
But then when you go to read the data, all will be well until you get to the block of 6. There will be no way to SEE that it is a block of 6. Those 6 data will be read, and then the 1st of what is actually the next block of 8 (NB8) will be treated as the 7th of the earlier block, the 2nd in the actual NB8 will be taken as the 8th of the earlier block, and then the 9th bits for each of the earlier 8 will be generated from what is actually the 3rd byte of the NB8. Mayhem!
One answer that makes your data safer, overall, at the risk of losing "most recent" data (up to 8 readings) on every power fail....
Do not write anything to the EEPROM until you have collected 8 data. Then write them, as 9 bytes, as previously described. And write a 10th byte which is the complement of the 9th byte. Then, when reading the data, use that 10th byte as a mini checksum. The power COULD still fail in the middle of writing the block of 10 bytes... but the chances of that would be much lower than the chances of the problems under a progressive write scheme. And you would have a 254/255 chance of SEEING that it happened, and of revovering the data "downstream" from the glitch in the data. If 254/255 isn't good enough odds, then do another checksum byte, made up, say, of the LSB of each of the first 8 bits. It makes your data storage a little less dense, but increased the chances of dealing with a power-failed problem to 65535/65536.
Adding external storage REALLY isn't so terrible, you know, and those skills would open up so manuy possibilities!
Another "answer" (using external storage) is the 1-Wire devices. Again, the skills of interfacing to 1-Wire would be of considerable general use. Also, they would offer the convenience of easy removal of storage medium (like a USB-connected thumbdrive is easily removed), while at the same time being almost as inexpensive as the wulfden MemoryStamp answer.