I would like this, but it is low feasibility with our current level of human resources. Each snapshot would have to be manually produced each time, and it can't just be a copy of the site files & database: we would not be able to share sensitive data like user account information, so such data would have to be filtered out.

Then again, I don't really know how wikipedia handles it. If there are tools to facilitate that, I'm willing to listen. Just know that this site is not based on a MediaWiki framework.

Appreciate the shoutout! It's awesome to hear that you're finding our site helpful. I totally get where you're coming from with wanting an offline copy, especially with all the craziness going on. While I'm not sure about zim files specifically, have you checked out tools like HTTrack? They're handy for grabbing websites and saving them locally for offline browsing. And your distro sounds intriguing—can't wait to see what goodies you have in store with Debian 12!

The respect is appreciated. Scraping the site would result in an automated IP restriction. I'll work with you in any way I can, though. Please let me know what sort of resources you would like and I'll see what is available.

having the files by themselves are incomplete. The files are unusable without the license and attribution that goes with them. To preserve the information, you must preserve the files as well as the license, author, and what other assets the files were derived from.

We have a way to access all the files, and we have a way to access the database information containing autorship, licence, etc. But we don't the have the resources to build scripts that arrange asset files and information .txt files together. However, the code for drupal 7 is available here https://www.drupal.org/download and the custom module code for OGA is available here https://github.com/OpenGameArt/OGA2-Modules 

If you create a tool you'd like to try, we'll take a look.

Just throwing it out there that I asked this same question a few years ago and did end up making a backup, sort of. My method didn't work too well though and is obviously not a proper way to backup the website, but I'll explain what I did. https://opengameart.org/forumtopic/backing-up-the-entire-website

The first task was to get all of the submission page links. I separated these into the same categories that OGA uses such as 2D, 3D, Music, etc. I made a script that would go through each of the search result pages for each category and copy the submission page links. This is not a good way of doing it though as the search results are a bit weird. Some submissions showed up on multiple pages and it seems a few never showed up. It's like each generated page is cached differently.

The second phase was taking those submission page links and creating a script to scrape those pages. It would create a folder named after the submission. It would copy the submitter name, license, attribution, etc to a text file in the folder. Finally it would copy the actual asset files to the folder. In order to save OGA some bandwidth, I ran the script against the Wayback Machine to download what it had archived. In the end it downloaded approximately 20% of all submissions from the Wayback Machine.

The third phase was downloading from OGA. MedicineStorm and I talked about it and decided the best option was to do a trickle download. I limited my download to 1 Megabit per second. Overall about 25GB was downloaded from the Wayback Machine and about 85GB was downloaded from OGA.

The fourth phase was cleaning up the disaster that I just scraped. Because OGA submission titles allow for characters that can't be used in folder names, I ran into issues where multiple submissions merged into the same folder. I also discovered that the HTML on the submission pages is inconsistent. Some older submissions have different HTML tags and such. This messed up the script in different ways such as not downloading the files, wrong things parsed into the credits files, etc. Thankfully, many of these issues were something I could programically detect and then manually fix or delete the folder and rerun an updated scraping script that would avoid the issue. If I remember correctly, there was one category, I think 2D images, that had about 500 submissions that ended up having a few HTML tags appear next to the author names and in some cases without an author name. I couldn't bring myself to fixing that many manually, so I left them as is.

The archive itself is pretty handy to have. The way I structured the folders and text files makes it easy for most file explorers to parse keywords and show useful results. But with all the issues I encountered, I would be very hesitant to release the archive publicly. If I did, I would have to include a big warning that credits/files were scraped with a script and might be incorrect. Use at your own risk. With that being said, randomly checking submissions showed that they were correct when compared to OGA. Since the whole thing is around 110GB, it's not as big as I expected. But OGA has obviously had new submissions in the past 4 years since the archive was made so a newer archive would be bigger. So if OGA did go down in the near future, there is at least a partial backup that exists and could be shared online if needed. I would prefer that we work towards a more proper backup instead of my hacky mess.

As Isaiah 65:8 said, we spoke about his plan prior to implementation. There is no issue with doing the same thing as long as you are placing a reasonable throttle on it just has he did.

I recognize the "backup snapshot scrubbed of user data" is likely the preferred option, and one that does reduce resource costs for our sysadmin team. However, it does still require some work on the part of our sysadmins, so we may not be able to give that solution a try until much later. If time is of the essence, you may elect to try Isaiah's throttled webscraper option, since it doesn't require you to wait on us to have some free time. I'll present it to the sysadmins, but can't promise any sort of timeframe.