@MaxJa4 unfortunately the backdating for the Azure test case here:

stops working when you run the test in a docker container, as you cannot change the date in a Docker container (you'd have to do it on the host). Any quick idea about how to do this differently, ideally on filesystem level? If you don't have a quick idea, no need to spend too many brain cycles on this, it's not urgent to get this merged and I can also look into it when I find the time. Thanks.

az storage blob upload uses the current server time as serverModified date. Which in this case is equal to the host. Setting the metadata manually via --metadata gets ignored, as well as the file's metadata.
I don't have an idea to trick Azure right now, costed me some time to figure out the above behavior.

Only idea would be if the azure mock container takes an argument for timezones... maybe that can fool it.
Edit: timezones aren't enough for a 14 day difference... haha
Edit2: Just found this and this.

Seems you can crack open the Azurite server and edit the timestamp in its object database (which is just a JSON file): 99a0617. Because what could go wrong ¯\_(ツ)_/¯

Seems like the most creative part of software engineering is figuring out how to test a system. Well, if it works, it works. Fine for integration testing haha. Good idea.

Saw this the other day: https://docs.docker.com/build/cache/backends/gha/ (and the official GH docs)
If that works with the new test setup, we maybe don't need to pull all the images anymore, only if there are new versions. At least that's how I understand it. Would reduce the 503 errors of docker hub and reduce CI run time. Just an idea :)

Yup, I am also pushing this hard at $DAY_JOB right now. Probably a good opportunity to actually try it out.

@MaxJa4 I think this is good enough to merge now, so I'll do it. In case you work on something in the future and this is causing problems our you can think of places for improvement, please let me know.

As for using the GH Actions cache, I could not figure out how to use it when pulling 3rd party images, which is the bottleneck here. Building the docker-volume-backup image itself is reasonably fast without a cache too.

There's also some docs here https://github.com/offen/docker-volume-backup/tree/1e39ac41f492c96fc3844cfc87ca969dded9d8a6/test

Great! Looking forward to test it out. The readme is also great to get started.