Mopquill
Active member
The point of this script is that it automatically does backups via a cron (or some other form of scheduled task), in order to make things a bit easier on users who know shell basics, but don't necessarily know XenForo/MySQL stuff. The old saying applies here: "Data you only have in one place is data you do not care about." The point of making a backup is to download them on some sort of regular interval, and transferring them elsewhere is beyond the scope of this script. Throw an scp in your cron if you want it, rather than making me do more work.
To the email option, that's just silly. Not only would many databases quickly exceed max file sizes, but email is slow, and usually not terribly secure. I wouldn't recommend emailing any database unencrypted, and backup encryption/emailing are also both outside the realm of this script.
Finally, to the restore option, XenForo specifically recommends using utf8_general_ci, and as such, backing it up as say, latin1, could be harmful to the integrity of the database. Besides that, automatic backups keep you from getting too far behind. This script ensures that you back up in the proper format, and at regular intervals. Once you have the backup, it's a simple import away from being restored. There's no reason you'd need to do an automatic restore, and restoring is not difficult. Besides that, I also think it's something best handled on a case-by-case basis. Needing to restore a database could indicate that there was corrupt data, a user that had too many privileges or went wrong, or many other things. Each of those things should be handled different. A rogue user should have his permissions pruned from the database *before* restoring it, and data corruption would have you searching records for where/when the corruption started, so you don't restore records that are just going to crash again. Automating this process seems counter-productive, and I think any users in dire need of being able to restore via script should either learn the bare minimum about MySQL, or otherwise invest in some sort of managed services.
I appreciate the suggestions, but they are useless to me (the primary reason I add anything to this script is because I think it will be useful to me, useful to many users, or useful to several users, yet trivial to script in), and I feel all of them fall outside of the scope of this script, and its very point. The only thing to date I've added that wasn't really necessary was pigz support (as it's far more likely that Disk I/O is bottlenecking you rather than number of cores), and I don't really intend to make more work for myself.
To everyone else, I've gotten backed up with many other projects, and I'm not actually completely sure which features I've added. I'll be going over the script hopefully in the near future, and getting it release-ready and efficient and whatnot. I think I've got some more testing to do, and I think @electrogypsy's suggest of rolling backups are still misbehaving. I'll try to get something out soon.
To the email option, that's just silly. Not only would many databases quickly exceed max file sizes, but email is slow, and usually not terribly secure. I wouldn't recommend emailing any database unencrypted, and backup encryption/emailing are also both outside the realm of this script.
Finally, to the restore option, XenForo specifically recommends using utf8_general_ci, and as such, backing it up as say, latin1, could be harmful to the integrity of the database. Besides that, automatic backups keep you from getting too far behind. This script ensures that you back up in the proper format, and at regular intervals. Once you have the backup, it's a simple import away from being restored. There's no reason you'd need to do an automatic restore, and restoring is not difficult. Besides that, I also think it's something best handled on a case-by-case basis. Needing to restore a database could indicate that there was corrupt data, a user that had too many privileges or went wrong, or many other things. Each of those things should be handled different. A rogue user should have his permissions pruned from the database *before* restoring it, and data corruption would have you searching records for where/when the corruption started, so you don't restore records that are just going to crash again. Automating this process seems counter-productive, and I think any users in dire need of being able to restore via script should either learn the bare minimum about MySQL, or otherwise invest in some sort of managed services.
I appreciate the suggestions, but they are useless to me (the primary reason I add anything to this script is because I think it will be useful to me, useful to many users, or useful to several users, yet trivial to script in), and I feel all of them fall outside of the scope of this script, and its very point. The only thing to date I've added that wasn't really necessary was pigz support (as it's far more likely that Disk I/O is bottlenecking you rather than number of cores), and I don't really intend to make more work for myself.
To everyone else, I've gotten backed up with many other projects, and I'm not actually completely sure which features I've added. I'll be going over the script hopefully in the near future, and getting it release-ready and efficient and whatnot. I think I've got some more testing to do, and I think @electrogypsy's suggest of rolling backups are still misbehaving. I'll try to get something out soon.
