There is a storage folder, but it does not contain folders with dates.

This is a misunderstanding. The folder names are 8-character random item keys. The thing about dates is just telling you to look at the dates of the folders to see when those attachments were added to Zotero, so you can tell if this is the same data directory you were using previously. But that section isn't relevant to your situation anyway.

You didn’t respond to anything in my first message.

zotero.sqlite.bak is from a month ago? If you've been using Zotero on this computer, you should have zotero.sqlite.bak and zotero.sqlite.1.bak from the last couple days in the data directory.

I haven't been using Zotero myself since mid July. This usually goes in waves when I am writing papers or preparing grants. Some of my students will have more recent versions.

It would be lovely to have a mechanism to restore a group/library online, just as there is a backups locally. Some kind of version control would allow us to see the counts of the number of references. I could then easily see when a specific group went from hundreds (or thousands) to zero.

Again, we can tell you who did this, but you need to tell us the group name via email.

Just adding a member and having them sync would never do this. Someone has to have deleted all items and emptied the trash.

As for backups, anyone using Zotero regularly should have zotero.sqlite.bak and zotero.sqlite.1.bak files from the last couple days. If someone hasn’t been using Zotero, those files would be older. Beyond that, it would just be any backups someone made of their own system (e.g., automated hourly Time Machine backups on a Mac).

I have emailed to find out who may have deleted these files. All group members are still a part of the project so if anything happened, it should probably be a user error.

Thank you for your help.

In the future, it would be great to have version control online so we can backup a single group that way.

First question, if a group member deleted the references (which I know would be an accident), why are they not in my trash?

Because the group member also emptied the trash. I can't tell you why they did this, but it's what they did.

Any group member that had been syncing would've been able to restore the group data for at least a couple days with the automatic local backups Zotero makes, but beyond that you would need your own backup (e.g., the automated backups from Time Machine on a Mac).

Second, question, is a group member able to delete a group? My group still shows up, but it is empty.

They can't delete the group itself, but they can make changes to it, and that by necessity involves deletions. We could consider making it impossible for non-admins to purge items (and soon collections) from the trash for 30 days, but there are downsides to that — e.g., it's fairly easy to save an item to the wrong library, so if someone saved something personal to a group by mistake, making it impossible to delete an item isn't ideal. There could perhaps be some sort of time limit — e.g., you could purge an item from the trash if it was created within the last 15 minutes.

Currently, the two steps to permanently delete items in a shared library are exactly the same as in the personal library:
I. Move to Bin
"Are you sure you want to move the selected items to the Bin?"
-> You can directly press Enter to validate Ok.
II. Delete
"Are you sure you want to delete the selected items?"
-> You can directly press Enter to validate Ok.

I think that the easiest things to improve would be:
1) Add the warning suggested above at step II in a shared library: "⚠️ The items will be permanently deleted for all members of this shared library." A similar warning could also be given in step I, but that is probably obvious and and less critical anyway. So better keep the warning at the most important step only to make it more efficient.
2) Change Delete to Delete Permanently at step II and the text below to "Are you sure you want to delete permanently the selected items?" (for both personal and shared libraries). This would be more consistent with the option given in the right-click menu on items in the Bin. And it does not cost much to be extra clear about this.
3) Make the default option to be Cancel instead of Ok when pressing Enter at step II (for both personal and shared libraries). Purging the trash of a library is not something that needs to be optimized for efficiency. So the small extra effort needed to press Ok is probably well worth it considering the extra protection it provides.

You can argue that no one reads dialogs anyway, but I still believe that giving more precise information in the delete popup is important.

Beyond these simple steps, in line with your ideas, an "Admin Bin" could probably be a good solution:
- Only admins can purge the bin permanently, with the additional warnings mentionned above.
- Other members can purge the bin for all users, but it goes to an Admin Bin sub-collection of the Bin collection only visible by admins, where they need to make a final purge to make it permanent. The member should be notified about this when purging the bin.
- Members can still make a permanent purge of the items that they have added to the shared collection. But all the items selected to be purged must be added by that same user. And eventually add an extra layer of validation (a tick Also delete permanently for the Admins before validating the purge) to make sure this is the intended behaviour. This is intended only for confidential items that were added by mistake, so it makes sense to make the process more painful.
- At step II, admins will always see the option to also purge the Admin Bin by clicking inside a tick box if the Admin Bin is not empty (which means that another member has purged the bin). This keeps the normal maintenance of the shared library very simple, with just a simple additional step triggered by purging event by other members.