Gotcha. I actually already read through DataStore2’s source code while working on my own variation. I would use your system, but I also like the experience of trying to do it myself 
5 Likes
I wouldn’t say that they would take down your game because of this. However, in general, I would say that Roblox does look down on this practice due to just the sheer amount of data.
4 Likes
It’s weird never had a data loss with using a basic system honestly
Now that I think about it, Roblox did add a RemoveAsync function a while back. I wonder if you could also set up a system to automatically remove older versions after they pass a certain amount in the OrderedDataStore. (ie: after 50 keys, the last key gets removed every time a new one gets added)
19 Likes
you surely could. I also use a bit other method of saving. Similiar, but other. Instead of timestamps i save play time so always the most progressful one are loaded (ensures than no older will be loaded).
1 Like
I had them from years. Nobody knew why… No errors, no issues. Just loss.
3 Likes
I would get fired from my job if I tried to save data like this.
If you want to prevent data loss, you could just swap between two different keys. If one is corrupt, use the older one.
As a developer, it is your responsibility to manage the data appropriately. Exploiting the fact that there is no data limit is no excuse for treating DataStores as infinite backup data storage.
(But do what you want I guess lol)
68 Likes
You could always use stuff like math.floor(tick()/604800) in order to make the backups weekly, instead of super spammy
4 Likes
At that point there’s no reason to use the berezaa method in the first place.
3 Likes
Why’s that? You would still have a long list of backups so if you screw something up you can just roll everyones saves back one week
Being able to roll back saves isn’t the primary benefit from using the method. You’d just be limiting yourself to the extremely restrictive OrderedDataStore limits for it.
2 Likes
Its only a matter of time before they retaliate to this method unless people set a cap on how many backups can be stored.
2 Likes
First off, you shouldn’t be auto-saving every 60 seconds. Saving when the player leaves, when the server shuts down (game.OnClose or bind to close), every ~3-5 minutes and whenever the player makes a robux purchase should be more than enough.
It’s also not stressful on the servers at all. It just costs Roblox extra money for the data storage, but the amount a single game saves is pretty much negligible in the grand scheme of things. Considering Roblox takes the vast majority of game income, this seems pretty fair to me.
Roblox doesn’t impose any limits on how much total data you can have saved, and I doubt they ever will because such a limit wouldn’t be very scalable.
I was only light-heartily joking when I said “Roblox hates me” for the way I save data. You shouldn’t run into any issues doing it like I do.
41 Likes
Additionally, consider keeping a per-player flag that gets set whenever an online player makes a change that requires a datastore update. There’s no point using disk space or datastore bandwidth to write multiple copies of unchanged data every 3-5 minutes. Especially if you’re going to keep only the last N saves, then it benefits you for them to be the last N unique datasets.
14 Likes
DataStore2 does this.
4 Likes
Just gotta watch out for table changes. If you are saving tables, then that means that the values inside the table are changing, and not the actual table itself, thus could be marked as ‘clean’ still and not get saved. I ran into this issue with my DataStore system.
4 Likes
Call it a hack, but DataStore2 always deep copies tables before setting/getting to stop this exact oversight.
This forces you to call :Set if you change the table.
3 Likes
Periodical autosaving isnt required and it only prevents data loss when the datastores crash. Traditional bind to leave and bind to close saving should work almost all the time as long as connection maintained.
1 Like
2022 Edit: It’s impossible to completely prevent all data loss. Fortunately, the reliability and resiliency of the Roblox Datastore backend has improved considerably since that post was originally made. Along with saving when a player exits the game, it’s a good idea to periodically autosave the players data. You can further mitigate damage by warning the player when their autosave has failed.
Datastores have a massive outage almost every weekend. You cannot rely on bind to close for data, ever.
15 Likes
Is it only big games that get hit by these massive outages? Because I 100% guarantee after setting up a pcall function using GetAsync inside a repeat loop that runs 7 times before giving up, I haven’t had a single case of data loss—and one of the first order of operations for any game I make is creating a Datastore module (nothing special, just using GetAsync & SetAsync) but then again, I don’t have a huge game that has to handle hundreds of thousands of players.