pterodactyl / panel

Pterodactyl® is a free, open-source game server management panel built with PHP, React, and Go. Designed with security in mind, Pterodactyl runs all game servers in isolated Docker containers while exposing a beautiful and intuitive UI to end users.

Home Page:https://pterodactyl.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add option to automatically stop server during backup

FrozenSoda opened this issue · comments

Is there an existing feature request for this?

  • I have searched the existing issues before opening this feature request.

Describe the feature you would like to see.

Many game server applications write to savefiles on the disk frequently while running. If such a write operation happens to occur during a backup, there is a risk that the backup becomes corrupted. Therefore it would be useful to have an option to automatically stop the server before initiating a backup, and restart it after the backup is finished if the server was previously running.

While the scheduler provides start, stop and backup actions, it does not wait for one task to finish before running the next, making it hard to mitigate the problem using the scheduler. (You can schedule the tasks at different times but then you have to guess how long the backup takes, which can vary depending on multiple conditions.)

Describe the solution you'd like.

Since probably not all server applications write to the disk frequently, it possibly makes sense to place this option in the Egg creation page and including the value in the Egg file, as well as providing the ability to override it in the specific server instances. For example, an option called "Stop Server during Backup" alternatively "Allow Server to Run During Backup" which can have the value 0 or 1.

An additional solution would be for the Egg to contain commands to pause/resume save operations which are executed before/after the backup (like save-all, save-off and save-on for Minecraft), but that might not be enough when you have plugins that also write to the disk unaffected by these commands (though they sometimes also have their own commands to pause/resume write operations), which means this solution can only be complementary to the first.

Additional context to this request.

No response

commented

Schedules you can save-all, stop server, do a backup and then start server again.
You just give the next start some larger time, depending how long your backup takes. Yes it's not perfect but it works™

Seems like you already know that which is good, personally would say that it's in the backup schedule itself not in the egg configuration.

Schedules you can save-all, stop server, do a backup and then start server again. You just give the next start some larger time, depending how long your backup takes. Yes it's not perfect but it works™

Seems like you already know that which is good, personally would say that it's in the backup schedule itself not in the egg configuration.

That is absolutely possible but if you backup to Amazon S3 and your server uses a lot of storage, backup can take quite some time. Additionally, the upload speed might vary and the server size might change with time (as you for example explore more in the case of Minecraft, or install additional mods to your server), which means it is difficult to predict how long the backup will take, and that this duration might change with time. Thus you need to overestimate the backup duration which means the server is offline for longer than necessary.

A feature in the scheduler which would solve this issue has been proposed in #2872, however that solution seems to be more difficult to implement, and it does not help if you forget to stop the server when manually taking a backup.

Duplicate of #2872
For the server to auto-start after the backup it would need to know when the previous task is completed.

Duplicate of #2872 For the server to auto-start after the backup it would need to know when the previous task is completed.

While that feature also would solve the issue, I wouldn't necessarily call it a duplicate. That feature is related to the scheduler itself while the feature I proposed would be embedded in the backup procedure, similar to how the backup restore operation automatically shuts down the server.