This is the resulting tarball for aarch64:

-rw-r--r-- 1 root root  23G Jan  6 10:46 eessi-2021.06-linux-aarch64.tar.gz

And a listing of its contents:
eessi-2021.06-linux-aarch64.tar.gz.list.gz

Should we provide the tarball via the new data repo? We could also replace the version via a symlink to somewhere under host_injections, that would allow us to add logic to check if they've unpacked the tarball and use the archived stuff in the initialisation (and advise them what to do if they haven't)

I definitely like the idea with the symlink! Storing the tarballs in the data repo doesn't really work at the moment, as they're way too large for the current setup. Then we should definitely use the approach with some external storage (S3 bucket) and only use CVMFS on top for the metadata / filesystem layer. So, for now, I'd propose that we just store it somewhere in an S3 bucket, and maybe we can set up the CVMFS repo that way later on (or make something like archive(d).eessi.io)?

+1 for just storing the exports in an S3 bucket for now

I've stored them in s3://eessi-archive/2021.06 on AWS for now.

Can we get S3 storage for free somewhere? I bet we can...