Secure Roblox Data Backup and Versioning
ESCOPO
This prompt produces a professional implementation of player data backup and versioning for Roblox, ideal for games that evolve inventory formats, currency, progression, pets, quests, or persistent stats. The system detects old versions, performs controlled migrations, and preserves recoverable snapshots before critical changes.
The requested output includes a central ModuleScript and a server startup Script, with DataStoreService, UpdateAsync, structural validation, retry with backoff, session control, history limits, and useful logs. The focus is safety, data integrity, and realistic production operation, without trusting the client.
The prompt also asks the developer to provide the game’s real structure, such as DataStore names, modules, RemoteEvents, and the current profile format. This way, the generated code can be adapted to the existing Explorer and be ready to paste into Roblox Studio and test.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, DataStoreService, schema migrations, and secure persistence systems for live games. Create a complete system for backing up and versioning player data across updates, adapted to the context of my game that I will provide below. The goal is to ensure that future changes to the data format — such as new inventory fields, currency, progression, pets, quests, skills, or settings — can be migrated without data loss and with the ability to recover previous snapshots. Before writing the code, consider and use the context I will paste at the end of this request. It may contain real names of objects in the Explorer, the current DataStore name, the profile table structure, existing modules, the loading/saving system already used, existing RemoteEvents/RemoteFunctions, attribute conventions, and gameplay requirements. If any essential information is missing, ask at most 5 objective questions before generating the code. If I do not reply, use configurable names at the top of the module and clearly document the assumptions; do not invent external dependencies or objects that are not necessary. Required architecture: generate 2 complete files. The first must be a ModuleScript named `PlayerDataVersioning`, located at `ServerScriptService/Modules/PlayerDataVersioning` (or the equivalent path indicated by me). It will be responsible for the current schema, data normalization, validation, incremental migrations, creation and reading of backups, secure serialization when necessary, and retention policies. The second must be a `Script` named `PlayerDataVersioningBootstrap`, located in `ServerScriptService`, responsible for connecting `Players.PlayerAdded`, `Players.PlayerRemoving`, and `game:BindToClose()`, coordinating loading/migration/saving, and integrating with my existing system. If my game already has a profile service, adapt the bootstrap to call it without duplicating concurrent loads or saves. Implement a robust data strategy: use a main DataStore for the current profile and a separate DataStore for versioned backups, with deterministic keys based on `UserId` and snapshot identifier. Every persistent change must use `UpdateAsync`, never `SetAsync` as the main concurrent update mechanism. Include an explicit `CURRENT_SCHEMA_VERSION` constant, a `SchemaVersion` field inside the profile, and a table/router of incremental migration functions, for example from version 1 to 2, from 2 to 3, up to the current version. Migrations must preserve unknown fields whenever possible, fill default values in a non-destructive way, validate types, prevent invalid values, and fail safely if a migration is impossible. Before applying a relevant migration, create a snapshot of the raw profile in the backup DataStore, containing at least `UserId`, source version, planned destination version, UTC time (`os.time()`), backup reason, unique snapshot identifier, and the original data. Do not save non-serializable Lua data, instances, functions, userdata, or DataStore-incompatible keys. Implement configurable retention, for example keeping only the 5 most recent backups per player, and explain in the code a safe strategy for listing/cleaning metadata without causing excessive budget consumption. If a full backup listing is not directly feasible with DataStoreService, use a per-player snapshot index maintained with `UpdateAsync` and handle failures resiliently. Also include a manual restore function, server-only, such as `RestoreBackup(userId, snapshotId)`, protected for administrative use by a configurable list of authorized UserIds or by an authorization function that I can connect to my admin system. Do not expose restore, backups, currency, inventory, damage, or persistent decisions to the client. Do not create new RemoteEvents unless necessary. If I provide existing RemoteEvents, treat any request received through them as untrusted: validate type, limits, permission, player state, and data on the server before executing any action. The client must never provide schema version, profile contents, balance, inventory, or which backup to restore without authoritative validation on the server. Implement professional error handling: `pcall` on DataStore calls, limited retries with exponential backoff and jitter, contextual log messages, prevention of simultaneous operations for the same player, load timeout, and defined behavior when DataStore fails. Prioritize not overwriting potentially newer data. If it is not safe to save, keep the player in a protected state and explain, in a comment, the policy adopted. Consider server shutdown with `BindToClose`, DataStore budget limits, and players leaving during pending operations. Deliver the response in Brazilian Portuguese and in this order: 1) architecture summary and assumptions; 2) exact tree showing where to place each file in the Explorer; 3) complete ModuleScript code; 4) complete Bootstrap Script code; 5) integration instructions if a data manager already exists; 6) Roblox Studio test checklist. Each file must be in its own Markdown block using exactly ```lua, with no pseudocode, no omitted snippets, and no use of `...` as a substitute for logic. Comment the code usefully, especially migrations, concurrency, backups, retention, and security. At the end, explain how to test with simulated players, how to artificially change an old version, how to confirm a created backup, how to simulate failures, and how to validate a restore without risking production data. Context for my game to adapt the solution: [PASTE HERE the relevant Explorer tree, DataStore(s), current profile format, existing schema/version, data modules, RemoteEvents/RemoteFunctions, admin IDs, save frequency, and specific requirements.]
