Storing the Earth using optimized storage methods.
Since the OP says the eyes can only see the "surface" of the Earth, we can assume that we do not need to capture the complex inner workings of the oceans or clouds, just the surface level. It's hard to estimate what the actually complexity of Earth's average surface is but, let's be REALLY generous and say that you will have an average of 100 surfaces you need to capture per unit area of the Earth's surface. If you want to assume a top-down projection of the Earth, then you can just remove 2 orders of magnitude from all of my following results.
This puts your total pixel data at ~5e26... and when you add in things like wire-frames, normal maps, etc. that 3-d models would need as additional overhead, you are looking at something closer to 1.1e27 bytes of data per frame... but we are not done here.
Most of the Earth's surface is either organic or mineral. Both of these things form highly repetitive patterns that are very easy to resample in other parts of your image. Your average exterior cell for plants and animals for example is 10-100 micrometers. Meaning if you find one type of cell, you can store a library of a few dozen to a few million samples of that kind of cell depending on how much fidelity you need and be able to generate a nearly lossless image all the way down to the micrometer scale.
Since a single plant can have a surface area of trillions of micrometers, but often has less than 10 kinds of surface cells, it means that a single plant can have enough repeating textures to make a 1 million sample library of each cell type increasing texture compression by 5 orders of magnitude, but if you then reuse that library across all of the trillions of instances of that plant before it evolves enough to need to resample, you could be looking at a total savings of 17 orders of magnitude on the texture mapping of that plant species... at least in pixel data... you would still need to call each cell that needs to be generated; so, while the pixel data has become immaterially small, actual compression would only be down to the cellular level of about 100-10000 times compression. As for the overhead of your pointers on such a large scene, through careful indexing, you can get away with relatively small pointers. So, your plant as a whole could have a meta-data set that builds your lookup tables for each library it needs, and from there each cell could use very short pointers, maybe 3 bytes per cell for the texture pointer, plus maybe 6 bytes for rotational and offset data. More general position data could be inhered from its position in your data stream. Since a single pixel is normally 6 bytes, this means you can achieve about 67 to 6667 time compression on most organisms.
Minerals are just as easy to generate libraries for because they form predictable crystalline structures. With less than 5000 common minerals here on Earth, and minerals not evolving, your library for these can be quite small, and your shapes very predictable. It's hard to say how compressible minerals are, but it is probably more so than plants.
So, overall I would estimate that you could get at-least 3000:1 compression on the Earth's land mass.
The Oceans are way easier to texture since there is only really 1 layer over most of the Ocean, and the whole thing only needs a single library... So we can drop two orders of magnitude right off the top to eliminate that 100 layer thing I added in to account for the complexity of minerals and organics. So Ocean compression is more like 300,000:1 from my total pixel data estimate.
Then there is the re-usability of data from one frame to the next. In a 3d video file, you do not save the whole state of each object for each frame, instead you only update them when at key-frames using tweening to approximate the in-between states. While plants, animals, and liquid water may change a lot from one frame to the next, minerals and ice do not. Minerals will often be able to go millions if not billions of frames before needing a new keyframe; so, mineral textures over time will take up a relatively negligible amount of space.
So, to estimate data usage, we know that the Earth's historical averages are that ~20% of the surface has been covered by dense life, ~70% by liquid oceans, ~10% by deserts and/or glaciers.
So the oceans need about 2.5e21 bytes per frame (1.1e27 * .7 / 300000)
Life needs about 7.3e22 bytes per frame (1.1e27 * .2 / 3000)
Deserts and glaciers need several orders of magnitude less per frame; so, I will just drop them as statistically insignificant.
This means you need ~7.55e22 bytes per frame in total.
Also, although life evolved ~3,770 million years ago, it only moved onto land about 430 million years ago. This means that we can completely throw out the Earth's landmass as "deserts and glaciers" for 3340 million years.
Before 430 million years ago, you only needed ~2.5e21 bytes per frame.
While humans can technically perceive "quality" differences up to 120 frames per second, you can generally sample speeds as low as 12 frames per second and most people will not notice an issue in the quality of the video. Especially if you use tweening tricks to simulate the intermediate frames. So if we assume 12 frames per second this means that you have ~1.0e17 frames before life moved to land and ~1.4e16 frames thereafter.
So your total dataset using compression is about (7.55e22 * 1.4e16) + (2.5e21 * 1.0e17) = 1.3e39 bytes.
Human memory is believed to be associated with pyramidal neurons which have an average of just over 5000 synapses, and there are ~57 billion pyramidal neurons in the human brain taking up about 2/3 of your brain's real-estate.
This means that the human brain can store ~4.5e16 bytes/m^3; so, you need 2.9e22 m^3 of pyramidal neurons to store the record using the compression methods as described above. If this brain were then organized into a sphere, it would have a radius of ~19,000km putting it somewhere between the size of Earth and Neptune.