Proposal for Implementing Flexible Periodic Automatic Backup Function in Palworld

[ghostzero94042]

Dear Developer,

The main issue with Palworld is not the difficulty of setting up the server, but rather the backup solutions. Currently, server software typically allows setting a backup interval and retaining a limited number of recent backups. However, Palworld's problem lies in the fact that most server software cannot accurately distinguish between automatic restarts and crashes. In cases of server crashes, backups may become invalid or be overwritten, leading to data loss.
Recently, Palworld is about to receive a major update. In response to the issue where server crashes may lead to data loss, I have a proposal for an experimental feature to add a periodic automatic backup function. The specific design is as follows:

Cycle Division:

Users can customize the backup cycle (e.g., 1 hour) and archiving frequency (e.g., backup every 5 minutes).
Archiving Management within the Cycle:

Each cycle will create an independent folder to store backup files.

At the end of the cycle, only the last backup file of that cycle will be retained, and the rest will be automatically deleted to save space.

However, this approach still has a flaw. Most Palworld servers' restart logic does not include a mechanism for pausing and restarting after a memory crash. It is common for servers to experience abnormal shutdowns due to memory or other factors, resulting in data loss. Typically, data can only be restored from backups. But if the server administrator does not notice in time, the backup data may be cleared, and new backups will overwrite the previous ones, leading to data loss.

For example, the server may crash at 3:54, restart, and then perform a backup at 3:55, deleting all backups from 3:00 to 3:50.

Therefore, I suggest setting the backup structure to use the computer date and time as the outermost folder, and the server's startup time as the starting point for backup calculations. This way, even if the server crashes and restarts, the cleared backup files will be recorded in a new folder named with the computer date and time, rather than overwriting the original backup data.

Example:

Assuming the server's startup time is 4:00 PM on December 20, 2024, the server will immediately generate a backup folder named 2024-12-20_16-00. After running for 3 hours and 30 minutes, the backup folder structure will be as follows:

2024-12-20_16-00 Folder Contents:
Cycle 1 Folder: Only retains the last backup (e.g., 00:55).
Cycle 2 Folder: Only retains the last backup (e.g., 01:55).
Cycle 3 Folder: Only retains the last backup (e.g., 02:55).
Cycle 4 Folder: Retains backups from 03:00 and all subsequent incomplete backups (e.g., 03:00, 03:05, 03:10, 03:15, 03:20, 03:25, 03:30).
At this point, 00:55 to 03:30 represents the server's running time, not the real-world time.

Then, if the server suddenly crashes and restarts, it will create a new backup folder named 2024-12-20_19-30 based on the current date and time. If the server administrator notices the issue 2 hours later, the backups during this period will be categorized into the 2024-12-20_19-30 folder. Although these backups may be useless, they will not overwrite the original backup data because they are stored in a new folder.

Therefore, whether it's an automatic restart or a crash restart, the server must generate a new backup folder to ensure that after each restart, the backup data is saved in a new folder and does not overwrite the previous backups.

The reason for adopting this backup approach is that backup intervals are typically set to half an hour or an hour, which may be too long to meet the need for quick recovery. Therefore, it is hoped to set shorter intervals, such as backing up every minute or every 5 minutes. However, this backup strategy usually only retains the most recent 15-30 backups because if backups are retained every minute for an entire day, the hard drive capacity will quickly become insufficient. If the server experiences an abnormal crash, the backup scheme usually does not pause but continues to overwrite the original backups until the server administrator notices the issue. To avoid this situation, it is hoped to implement a dual-saving scheme that simultaneously performs hourly and minute backups. This way, even if the server crashes, important data will not be overwritten and lost.

I hope the developer can adopt my suggestion.