search

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.
https://pterodactyl.io
Other
6.84k stars 1.74k forks source link

Also make a backup of the database(s) #2571

Open VibeGAMESNL opened 4 years ago

VibeGAMESNL commented 4 years ago

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like It would be nice if the backup feature also will make a backup of the database(s) if present.

parkervcp commented 4 years ago

A database could easily be many gigabytes. This could be larger than the actual game files too due to this.

VibeGAMESNL commented 4 years ago

A database could easily be many gigabytes. This could be larger than the actual game files too due to this.

Depends on the game. Mabe make it an option?

tinyoverflow commented 4 years ago

Backing up databases should, in my opinion, be a separate option and should not relate to the filesystem backups. Just because someone needs a filesystem backup doesn't mean he needs a database backup and vice versa. Also just because someone restores something from a backup doesn't mean he wants to restore the database.

notAreYouScared commented 4 years ago

Due to them possibly being huge... Couldn't we just stream it to the end-user as a download as it's being generated so it's not stored?

matthewpi commented 3 years ago

How would people feel about backing up databases separately from servers? Due to the way databases are treated, backups would need to be handled either by the panel itself or the queue worker, so storing them as apart of regular backups would be quite difficult. This also means you could restore database backups separately from server backups once that functionality is added.

TekExplorer commented 3 years ago

Seems like the logical thing to do, since databases really are separate from servers to begin with, so why not go the same way for backups?

VibeGAMESNL commented 3 years ago

Sounds great! Could you also add the database function to the scheduler?

matthewpi commented 3 years ago

Sounds great! Could you also add the database function to the scheduler?

Yes, that would be apart of that.

tinyoverflow commented 3 years ago

How would people feel about backing up databases separately from servers? Due to the way databases are treated, backups would need to be handled either by the panel itself or the queue worker, so storing them as apart of regular backups would be quite difficult. This also means you could restore database backups separately from server backups once that functionality is added.

This is literally what I suggested here: https://github.com/pterodactyl/panel/issues/2571#issuecomment-717679156

kakduman commented 3 years ago

I like this idea! An alternative idea could be a new way to specify databases to ignore in a .pteroignore file, which would resolve the issue of backing up unnecessarily large databases.

matthewpi commented 3 years ago

I like this idea! An alternative idea could be a new way to specify databases to ignore in a .pteroignore file, which would resolve the issue of backing up unnecessarily large databases.

The option to backup databases would be per-database, not all of them in one. Also an ignore file wouldn't work as we would most likely use mysqldump or something similar to backup an entire database. If you were suggesting to selectively backup tables from a database, this would become more problematic as restoring the database from a backup is that much more complicated to not drop the tables that were not backed up.

tinyoverflow commented 3 years ago

Backing up only some tables is way to specific for a backup system in Pterodactyl. At least in my opinion. While it is technically possible to use the .pteroignore file, I won't recommend to do that:

  1. The database server might not be on the same host as the gameserver, therefore the system would need to retrieve that file from a host which technically may have nothing todo with the backup itself.
  2. This would require additional syntax design and may make the .pteroignore file way to complicated.

From a UI/UX perspecive: Splitting the Backups-page in the panel in two parts: Filesystem Backups and Database Backups seems to be a great way to make it accessable to the user. Both Backups have nearly the same UI: A name and an exclude list. The database backup would create a backup for every single database that is associated with that specific gameserver, except for the ones that are mentioned in the exclude-list. The same would apply to scheduled database backups.

matthewpi commented 3 years ago

Backing up only some tables is way to specific for a backup system in Pterodactyl. At least in my opinion. While it is technically possible to use the .pteroignore file, I won't recommend to do that:

  1. The database server might not be on the same host as the gameserver, therefore the system would need to retrieve that file from a host which technically may have nothing todo with the backup itself.
  2. This would require additional syntax design and may make the .pteroignore file way to complicated.

From a UI/UX perspecive: Splitting the Backups-page in the panel in two parts: Filesystem Backups and Database Backups seems to be a great way to make it accessable to the user. Both Backups have nearly the same UI: A name and an exclude list. The database backup would create a backup for every single database that is associated with that specific gameserver, except for the ones that are mentioned in the exclude-list. The same would apply to scheduled database backups.

It wouldn't be stored in a file on the server regardless, the .pteroignore file is parsed for file backups only and shouldn't be used for databases in any way. There is also not really a practical use for any ignore like feature when backing up the database as you would backup each database individually, not to mention we are dumping the entire database into a single file.

The way I see the UI being done is by having an option on the context menu of databases to show their backups, then opening a modal listing all backups for that database with an option to create a new backup, however I could see why somebody might want this on the existing Backups page either mixed in or as a separate tab.

tinyoverflow commented 3 years ago

It wouldn't be stored in a file on the server regardless, the .pteroignore file is parsed for file backups only and shouldn't be used for databases in any way. There is also not really a practical use for any ignore like feature when backing up the database as you would backup each database individually, not to mention we are dumping the entire database into a single file.

Of course each database (sX_) should be dumped into it's own file. As said, the .pteroignore file should not* be used for that for, for example, the mentioned two reasons.

What do you think about my opt-out suggestion? It would be exactly the same as with filesystem backups: By default, when creating a backup, it would backup ALL databases (into their own respective files) except for those listed in the exclude list. To make it a little bit easier a list of checkboxes, one for each database, could be useful where all checkboxes are checked by default and the user can uncheck them if wanted.

by having an option on the context menu of databases to show their backups

I absolutely do understand why you might want to have this feature sitting on the Databases page. But as we already have a Backups page (and removing that isn't an option in my opinion) it would make more sense for the end users to have all backups there: File System and Databases.