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

Prevent imminent backups if no players logged in or server started since last backup #519

Closed
benbaptist opened this issue Jan 31, 2018 · 10 comments

Comments

@benbaptist
Copy link
Owner

benbaptist commented Jan 31, 2018

This would be an awesome setting to have - and one that should probably be on by default, but definitely should be possible to turn off. This would prevent needless, countless backups in which no player activity took place, and hence no realistic need to have redundant backups. I want to be able to backup extremely frequently (sub 15 minutes!) without wasting tons of space during idle hours when the server isn't even being played on.

EDIT: Oh, also - I'm starting to get back into playing with Wrapper.py and such myself, so I hope to start actively partaking in the coding activity once again!

@suresttexas00
Copy link
Collaborator

try writing that as a plugin first. Backups now has it's own API: https://github.com/benbaptist/minecraft-wrapper/blob/master/documentation/backups.rst

while I am thinking of it, that method adjustBackupInterval(self, desired_interval) may have units of minutes now, not seconds...

@suresttexas00
Copy link
Collaborator

I think we could create a backup option to backup only "changed files" versus the whole-backup schema we currently use. If you check the gittter feed, you will note that user lukeeexd reports backup times in the 5 minute range. Doing them every 15 minutes (i.e. an entire backup) could be asking for trouble. That means 1/3 of your run-time will be with a server in the save-off state!

We could definitely create a more intelligent back up system. I would like to see our existing code released in a formal 1.0.0 version first.. And I think we are close once I put final touches on Web and take care of our more serious bugs.

@suresttexas00
Copy link
Collaborator

Even if compressed, I am sure backups are serious load on (usually valuable) SSD space. By the way, may I suggest (if you are not already doing so) setting a backup path that is not on the SSD device? You can use an absolute path to another location outside wrapper's directory, for example:
"backup-location": "/home/surest/Desktop/backup-directory",

@suresttexas00
Copy link
Collaborator

suresttexas00 commented Feb 1, 2018

I labeled as Implement as Plugin because I think this feature is somewhat custom and actually easy to do as a wrapper plugin. The plugin API for backups allows you to start and stop backups, change their frequency and number of saved backups, as well as disable and re-enable backups.

That is not to say that I would not like that more intelligent (and faster) backup system...

Just saying that the issue 'as stated' is solved. Potentially, this is as simple as your plugin executing self.api.backups.disableBackups() when your playercount goes to zero... then running enableBackups() when a player logs in...

You might also register the wrapper.backupEnd event to mark your starting point for checking of all players are gone...

@suresttexas00
Copy link
Collaborator

We need to have a hints and tips page...

@benbaptist
Copy link
Owner Author

benbaptist commented Feb 3, 2018

I am already using backups on a non-SSD device. In fact, they're actually going to one of my networked servers with plenty of HDD space, which eventaully finds itself on my unlimited GDrive.

I guess I did say "wasting tons of space", but my main concern was just annoyance of having to go through hundreds of useless backups when wanting to retrieve a backup from a particular date rather than space. I have unlimited storage on my Drive account, so it technically doesn't matter, storage-wise. So the concern was more about the clutter.

I agree that a more intelligent backup system that only backs up necessary changes would be nice, but should not be a replacement. Some people do prefer having full, un-adulterated backups for 100% assurance and thoroughness. A temporal-compression system would have more effort (either from the user or from the underlaying software) to perform a proper restoration - and the loss of one backup or some other issue could potentially result in any backup being able to properly be restored. Temporal backups are better for short-term backups (perhaps within the last 24 hours, etc.) rather than long term backups.

@suresttexas00
Copy link
Collaborator

That being the case, as the backups are date-time stamped (and thusly sortable), is the cost of looking for a particular date worth the effort?

I will say that temporal backups are probably worth the effort and should be a config optional item :)

@suresttexas00 suresttexas00 changed the title Prevent imminent backups if no players logged in since last backup Prevent imminent backups if no players logged in or server started since last backup Feb 19, 2018
@suresttexas00
Copy link
Collaborator

I'm expanding this IAW the new title. I will probably "delay" the backup timer while server is stopped and implement the player timer whilst at it.

@suresttexas00
Copy link
Collaborator

Ok, this is what I came up with:

  • while no player is on, backups are paused, even if they go past their timer.
  • Once that first player logs in, the timer (which has been counting all along), will immediately activate again, probably spurring an immediate backup if some time has passed, depending on the backup interval setting.
  • Once the last player logs off, the timer again pauses.
  • If the server restarts during a pause, the world will save and wrapper will restart. The timer will start over, but be paused, waiting for a player.

This only took a few lines of code and I think it covers most things since, if a griefer came on, the world would probably backup when he logs on; and anything he is doing wont be a part of that backup!
I actually see no reason to do force a backup of the last persons changes, since those will be the most current anyway (and could be the griefers work), so I am simply implementing this will no ability to turn it off. Anyone wanting to counter-mand this behavior may simply force a backup with a plugin!

This will be in 1.0.b5 (beta build 5)

@suresttexas00
Copy link
Collaborator

#532

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

No branches or pull requests

2 participants