Add backup functionality

[brahmlower]

Dan has implemented backups using a mixture of shell, cron, and rsync (see minecraft-backup.j2) while Matteo is using the built in FDB update utility for the modded servers (see cron definition). Both methods seem appropriate for their respective server type, so I think we should implement both. My first thought is to break these two processes into different plays backup-ftb.yml and backup-cron.yml and then run them based on a backup variable:

Example defaults/main.yml

...
minecraft_server: minecraft
minecraft_backups: cron
...

Example tasks/main.yml

...
- name: Configure {{ backup_method }} backup method
  include: "backup-{{ backup_method }}.yml"
  when backup_method is defined
...

This seems like it would scale nicely as various server types are added. Not sure if there are obvious issues I'm missing though.

[benwebber]

Things like backups are tricky to do well because they're generally very site-specific. It's hard to offer a one-size-fits-all script.

I would definitely like to offer some general solutions as opt-in "contrib" features. That would go along with packaged hook includes (#8).

For example,

---
minecraft_enable_backups: true
minecraft_backup_method: s3
minecraft_backup_s3_container: s3://backups/minecraft

You can set a default, server-specific value for for minecraft_backup_method using some include_vars or set_fact magic.

Question: does the FTB backup utility do anything special? Or can you back up FTB by saving the server and copying the server directory as well?

[joshuacherry]

The FTB Backup utility doesn't do any magic that we couldn't do with standard linux tools. The backup utility only does a couple things:

1. Creates a backup folder inside the minecraft directory, if it doesn't exist.
2. Creates a zip archive of the world folder.
3. Creates a .json file listing all backups

I use cron to automate this screen -S minecraft -p 0 -X stuff 'ftb backup start\n'

[benwebber]

That's sufficiently specific enough that I wouldn't want to script it.

I use cron to automate this screen -S minecraft -p 0 -X stuff 'ftb backup start\n'

N.B. server commands like this will only work under systemd. Under systemd we attach a named pipe to standard input, so you can write to that file instead of using screen.

There might be a Bash exec hack out there to attach stdin to a named pipe in Supervisor, but I really want to deprecate Supervisor completely.

[joshuacherry]

but I really want to deprecate Supervisor completely.

I agree with this statement. It's a bit outside the scope of this issue but this is related to a different issue I've been having with the feature matrix. Currently we have tests for Ubuntu 14.04 using Supervisor, however our tests do not seem to work for any docker version above 1.10.2-0~trusty. For the moment this isn't a huge issue since Travis is still on Trusty and can use that version, however any docker testing on newer docker versions seems to hang after executing the ansible playbook.

If we deprecate Supervisor, I would expect to deprecate support for Ubuntu 14.04 as well. This isn't a huge issue yet but if/when Travis updates their environment it will escalate in importance.

Also, considering Supervisor is only really necessary for Ubuntu 14.04 support it could cut down on the complexity of our role to stick with a single process control.

[brahmlower]

Should we move the discussion for deprecating Supervisor support to its own issue?

That's sufficiently specific enough that I wouldn't want to script it.

We don't necessarily need to script that process though, right? Regardless of the backup method, we could use cron, which would end up calling a one liner specific to the backup method:

• Vanilla: Create an archive of the world and store it somewhere else.
• FTB: Pipe the backup command into the console, letting the FTB configuration handle the location

Actions like storing the archives on s3 seem like something that would be handled by another role.

[benwebber]

We don't necessarily need to script that process though, right? Regardless of the backup method, we could use cron, which would end up calling a one liner specific to the backup method:

That's what I mean: let FTB's tools do it.

Actions like storing the archives on s3 seem like something that would be handled by another role.

I somewhat agree, because everyone has their own way of doing backups. That's is why I suggest making that functionality opt-in. Although we could simply say "here's how to create an archive using this role, it's up to you to move it elsewhere."

include_role is pretty cool for this sort thing. It lets you distribute tasks with your role that you don't call by default.

[danizen]

The problem with supporting backup is the many, many ways to do backup. If you want a pretty generalized mechanism, you could use duplicity to S3, or you could use simply ask the user to pass the name of a script to be invoked to do backup.

Many servers handle backup with plugins within Minecraft itself...