The previous launcher would ask you to backup prior to updating.
While not terribly useful, this would still be useful to have.
Possibly add an option to store only the last N backups to prevent filling the disk with backups.
The previous launcher would ask you to backup prior to updating.
While not terribly useful, this would still be useful to have.
Possibly add an option to store only the last N backups to prevent filling the disk with backups.
<replace this line with the file content>
<replace this line with the file content>
Another use case regarding control over update-related backup behaviors:
Jul 31 22:51:18 stars SMDev: [ZIP] Zipping folder: /opt/devStarmade/./StarMade/server-database to backup-StarMade-0.198.485-20160719_005153_1470005472878.zip.tmp (Filter: backup-StarMade-) Jul 31 23:52:01 stars SMDev: Copying Backup mFile to install dir... Jul 31 23:52:01 stars SMDev: Copy to: /opt/devStarmade/./StarMade/backup-StarMade-0.198.485-20160719_005153_1470005472878.zip Jul 31 23:53:44 stars SMDev: [BACKUP] DONE
That's log entries from our dev instance, although I could also pull a copy from our staging install as well. In both dev and staging, there is absolutely zero value in such a forced backup, as server-database/ data had JUST been populated by a dump from production's most recent backup. Yet we're forced to wait over an hour before an update can actually be applied. In our specific circumstances, there's also zero value in a forced backup of production, as we already handle that at every server restart/startup.
For server operators, a command-line switch to enable forced backups (defaulting to true) would be ideal.