Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

希望新增灵活的周期性自动存档功能。 #51

Open
ghostzero94042 opened this issue Dec 20, 2024 · 1 comment
Open

希望新增灵活的周期性自动存档功能。 #51

ghostzero94042 opened this issue Dec 20, 2024 · 1 comment

Comments

@ghostzero94042
Copy link

开发者您好,最近帕鲁世界即将迎来重大更新。针对目前服务器崩溃可能导致数据回档的问题,我有一项关于自动备份的建议,不知道您是否仍在维护这个项目,但我还是想提出一个建议。

建议新增一种周期性自动存档功能,具体设计如下:

周期划分:

用户可自定义备份周期(例如1小时)和存档频率(例如每5分钟存档一次)。
周期内存档管理:

每个周期会建立一个独立的文件夹来存放备份文件。
在该周期结束时,仅保留该周期的最后一份备份文件,其余文件自动删除以节省空间。
但这个方案仍然存在一个缺陷,因为大多数帕鲁服务器的重启逻辑并没有包括内存崩溃暂停重启的机制。经常会遇到服务器因内存或其他因素导致异常关闭,进而丧失数据。通常情况下只能通过回档来恢复数据,但如果服务器方没有及时发现,备份数据被清空后,新的备份往往会覆盖掉之前的备份,造成数据丢失。
有可能在3:54时服务器异常崩溃,重启后恰好在3:55进行了备份,并将3:00至3:50之间的备份数据全部删除。
因此,建议将备份思路设定为以服务器日期和时间作为最外层文件夹,并以服务器启动时间作为0:00开始计算备份。这样,即使服务器崩溃重启,清空的备份文件也会被记录在新的服务器日期和时间的文件夹内,而不会覆盖掉原有的备份数据。

假设服务器开机时间为2024年12月20日下午4点,那么服务器启动时会立即生成一个备份文件夹,命名为2024-12-20_16-00。
而服务器运行了3小时30分钟,备份文件夹结构如下:
2024-12-20-16-00文件夹內容有
第1周期文件夹:仅保留最后的备份(例如 00:55)。
第2周期文件夹:仅保留最后的备份(例如 01:55)。
第3周期文件夹:仅保留最后的备份(例如 02:55)。
第4周期文件夹:保留03:00以及当前所有未完成的备份(例如 03:00, 03:05, 03:10, 03:15, 03:20, 03:25, 03:30)。
此时的0:55~3:30是服务器实际运行的时间,而不是现实中的时间。

然后,假设服务器突然崩溃重启,服务器会根据当前的日期和时间新增一个备份文件夹,命名为2024-12-20_19-30。
并且服务器管理员在2小时后才发现问题,这段时间的备份会被归类到2024-12-20_19-30的文件夹中。虽然这段备份可能无用,但由于它被存放在新的文件夹中,因此不会覆盖掉原先的备份数据,确保原有的备份不会丢失。

因此,无论是自动重启还是崩溃重启,服务器都必须生成一个新的备份文件夹,确保每次重启后,备份数据能够保存在新的文件夹中,而不会覆盖之前的备份。

@ghostzero94042
Copy link
Author

补充说明:希望采用这种备份思路的原因在于,通常备份时间设置为半小时或一小时,但这种间隔过长,可能无法满足快速恢复的需求。因此,希望能够设置更短的时间间隔,例如每分钟或每5分钟进行一次备份。然而,这种备份策略通常只会保留最近15-30次的备份,因为如果保留每分钟的存档一整天,硬盘容量很快就会不足。若服务器发生异常崩溃,备份方案通常不会暂停,而是会继续覆盖原有的备份,直到服务器管理员发现问题。为了避免这种情况,希望能够同时实施每小时备份和每分钟备份的双重保存方案,这样可以确保在服务器崩溃时,重要的数据不会被覆盖丢失。希望开发者能够采纳我的建议。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant