Backup Database, email, other running systems.

BIT does provide those scripts as well. Take a look at http://backintime.le-web.org/documentation/usercallback/

Here is an example script

#!/bin/bash
profile_id="$1"
profile_name="$2"

case $3 in
    1) #Backup process begins
        ;;
    2) #Backup process ends
        ;;
    3) #A new snapshot was taken
        ;;
    4) #There was an error
        case $4 in
            1) #ERROR The application is not configured
              ;;
            2) #ERROR A 'take snapshot' process is already running
              ;;
            3) #ERROR Can't find snapshots folder (is it on a removable drive ?)
              ;;
            4) #ERROR A snapshot for 'now' already exist
              ;;
        esac
        ;;
esac

Regards,
Germar

Very nice. May I request that you start a "user contributions" section for folks to add (or use, or request) scripts? May I also suggest that you start the ball rolling with some common scripts such as those that might be used for mySQL and perhaps something like dovecot maybe?

And if you do so, may I also request that you create them in a manner such that they are independent of each other? Meaning that one could decide to use script 1 and 4, but not 2 or 3 or 5, rather than lumping them all into one user-callbacks script.

Lastly, if you could add something to the GUI so as to enable or disable these individual scripts. It might be easier to create a callbacks directory, but that's for you to decide of course. Maybe even use /etc/init.d/ style boot scripts in case it made sense to do them in a particular order for some reason. That way one could select "Dump mySQL database prior to backup" or something like that from the GUI - where that quoted comment came from the script itself as a "title comment" perhaps. In essence you'd scan through all the available callback scripts, create checkbox buttons on the fly using the titles from inside the scripts.

Then I think you'd have a hands down winner, no competition backup program. In my opinion anyway.

Thank you kindly.

GUI is already a bit overloaded in my opinion. I like KISS (keep it stupid simple). User-callback is more an advanced users option which would confuse normal users.

A callback directory can be easily made with a shell-script which will call all scripts inside that dir, paste all args to them and sum up the returncode.

I agree with you that it would be great to have a repository with user-contributed scripts. I'll add a branch for this in which you could merge yours if you want.

Okay, here is the branch with two example scripts
https://code.launchpad.net/~bit-team/backintime/user-callback

I agree with you on KISS theory. I also agree with you that user-callback is an advanced option, and is precisely why I think it needs to be in the GUI, rather than hidden "under the hood". It's also why I suggested using "title comments" as I demonstrate below.

I think adding one more tab to the Settings window perhaps called "Scripts" or perhaps called "Pre/Post Backup" or even "Helpful Options" or anything other than "user-callback" would be a benefit. (The term "user-callback" itself is something programmers use - normal users just have checkboxes.) The scripts themselves are hidden away in a directory, and as far as the "normal" user is concerned they're merely additional options to choose. User supplied scripts simply show up as appropriate. I picture it something like this:

[[Helpful Options]] <<<< Tab Title

"Pre-Backup Options" "Post Backup Options"
----------------------------- --------------------------------
[x] [Stop mySQL & Dump Databases] [x] [Delete Dump Files & Restart mySQL]
[-] [Shutdown Dovecot] [-] [Restart Dovecot]

Wouldn't you agree that checking off one or more of the above is pretty simple from a normal user standpoint?

On the other hand, I do see your point as to how the script solutions could get complex in order to ensure the right versions show up. There would have to be a defined format to use/build user-supplied scripts. For example, assuming the script was built for ubuntu & debian then something like:

# Pre-Title: Stop mySQL & Dump Databases
# Post-Title: Delete Dump Files & Restart mySQL

# OS: ubuntu
# Versions: 12.04, 12.10, 13.10

# OS: debian
# Versions: xx.yy

It would probably be trivial to call an existing /etc/init.d/ bootup script for those cases where it existed (like mail).
StartScript="/etc/init.d/S20mySQL start"
EndScript="/etc/init.d/K20mySQL stop"

Your code would have to check the script Versions against the current OS in order to select the right scripts/titles to display.

>>A callback directory can be easily made with a shell-script which will call all scripts inside that dir, paste all args to them and sum up the returncode.

Easy for you... I'm not sure I could get from here to there without a whole lot of pain and suffering.

Hmm. I had "Pre-Backup" & "Post Backup" in two nicely spaced apart columns. launchpad ate all the extra spaces. But I'm sure you know what I meant.

Hi Andrew

I think these user-callback scripts are very specific for every single user. Everyone how need something like this has a different system with different needs. I don't think it would be possible to provide scripts that are as easy as check on/off.

And to be honest I don't have time to write and maintain such a bunch of scripts that would be necessary. For example you'd like to have something for MySQL and Dovecot. Someone else prefers PostgreSQL and Cyrus. Next we have Debian/Ubuntu ArchLinux Fedora etc. and all of them have their own oddities especially when it comes to servers.

I'm happy to help everyone with creating such scripts and it is a great idea to share them in that branch above. Please don't get me wrong, I really like your idea. But I think, providing such scripts ready for everyone would be to much for me.

BTW you don't need/want to stop MySQL for backup. You can dump a running MySQL with 'mysqldump'.

For the callback dir please take a look at
http://bazaar.launchpad.net/~bit-team/backintime/user-callback/view/head:/user-callback.multiple-scripts

Kind Regards,
Germar

Thanks for your response. I agree that user-callbacks are specific to the OS and often the version of the OS, as well as the specific tools and versions of the tools.

I'm not asking that you write "a bunch" of scripts (nor necessarily maintain) - just the first one so that you can establish the format that all others can follow by example. Otherwise you will in fact have a clash of styles and inconsistencies in how scripts are written and it will end up as a big mess, and then become impossible to add to the GUI (or require everyone rewrite their scripts a second time which will likely never happen).

Second, I am in fact asking that you establish the format of such scripts - by way of example as noted above and referred to below.

Third, I'm requesting that you provide an extra tab in the GUI, which is (potentially) populated as I previously described in a prior post - with checkboxes and script titles. This population would depend on the format you establish so that all scripts can be enabled or disabled by using the checkboxes. I provided an initial sample format for this purpose, tweak it however you choose so that it makes sense and works.

Fourth, something would (should?) in fact have to validate versions and an error message generated if there was a version mismatch, so that the user could fix it. I suppose you might even think of these scripts as plug-ins. How nice - BackInTime supports plugins! What a great feature to have! :) Hands & shoulders above the rest.

Thank you

I was just thinking that the format should probably also include the name of the utility and versions, as well as what's being affected. So for example:

# Affects="mysql"
# AffectsVersion="mysql Ver 14.14 Distrib 5.5.37, for debian-linux-gnu (i686) using readline 6.2"
# Utility="mysqldump"
# UtilityVersion="mysqldump Ver 10.13 Distrib 5.5.37, for debian-linux-gnu (i686)"

Those are version strings directly from each program (-V command line option). They could likely be stripped down to the essentials, but someone else would know better than I. Again, these are simply for the sake of example as to potential formats that could be put inside user contributed scripts.

As utilities change over time, these scripts would simply be "stock-piled" and new scripts written as needed. The old scripts would remain available. Might be cleanest to create additional sub-directories so all the mySQL scripts wouldn't get mixed up with all the postgres scripts or dovecot scripts or whatever.

Again, just some ideas it would be nice to see implemented.

Thanks for a great program!