You can close this support issue. Things may have improved with 3.2 since editing files on the system did not appear to initiate backups like my previous version.

JIRA's scheduler for running services works in (as you say) a pretty nonsensical way - it runs once when the webapp starts up, and again after X minutes (the delay setting), making it impossible to schedule things like nightly backups. See:

http://jira.atlassian.com/browse/JRA-6132

Apart from a webapp restart, or the delay period expiring, nothing in JIRA triggers the running of services.

If you need the backup service to run at a particular time, I'd suggest setting up an external process (like a cron job), which will backup the database (and attachments) with native tools (mysqldump, pg_dump etc).

First, I want to say that it's not just manually editing files that causes backups in the middle of the day. When I check the backup folder I see it happens sporadically, likely keyed to some administration setting I'd changed - but definitely not any file - .vm or otherwise. Further, the one place that it makes absolutely no sense to trigger the backup is the actual setting of the backup delay - since in order for it to be effective for a daily backup, it needs to be set in the middle of the night, when I prefer not to be in the office.

Please forward more information on the restart issue - but we plan to migrate to external SQL server soon, so maybe that problem will go away.

Thanks

Neal

Neal,

I think your app server is restarting JIRA when you edit the *.vm files on disk. All services run once when JIRA starts, and then X minutes afterwards (1400 in the case of the backup service). There is an issue open addressing this shortcoming:

http://jira.atlassian.com/browse/JRA-1865

However, generating a backup shouldn't affect users substantially - I suspect it is the JIRA restart that is affecting users. On Tomcat at least, you can disable this behaviour by setting reloadable="false" in the config file.

Cheers,
Jeff