Application backups

AlbumPlays can be easily configured to run and manage a comprehensive backup repository.

Neither MediaMonkey nor AlbumPlays are any more prone to data corruption than other computer applications, but you may have a lot to lose. It is true that Last.fm is an offsite backup of sorts, as it has a record of all of your scrobbles, but you could lose your track tags, your track ratings, and all of the work that it took to match your scrobbles to MediaMonkey’s database if you seeded the database using historic scrobbles.

AlbumPlays application backup features

  • AlbumPlays application backups are turned off by default
  • once backups are configured, AlbumPlays backs up both the AlbumPlays and the MediaMonkey databases together, to ensure synchronisation
  • it will automatically maintain a multi-version backup repository, so that you can restore back to a database version predating any data corruption
  • it automatically maintains a multi-level backup repository, required to cover catastrophic events such as theft of your computer or fire. Separate repository levels may be stored on your PC, as well as on a network drive, and|or offsite at a free Dropbox account.
  • set and forget: AlbumPlays monitors the schedule, automatically runs the backups, transfers backups between levels as required, and also house-keeps to delete any excess copies

Configuration: step one: start making backups

By default AlbumPlays makes no application backups.

You first need to start AlbumPlays making backup copies of your databases. You do this by telling AlbumPlays how often to make a backup; ie how many days to wait between each backup.

This is achieved via a modification to the configuration file as described here.

AlbumPlays will then take the backup copy when you close AlbumPlays, as directed by this backup schedule.

It is designed to make the backups when your close AlbumPlays so that you may open and use the application without delay, and you may then get on with other things while any backup task is completing.

  1. When a fresh backup copy is due to be taken, AlbumPlays will advise you to close MediaMonkey for the duration of the backup. … Closing MediaMonkey is optional. If you are not using it play or update anything, it may remain open, but it is safest to close it for the duration of the backup.
  2. You will experience a variable duration taken complete shutdown, as it will depend upon whether a fresh backup is required according to your backup cycle, or it may need to distribute, via the Internet, a backup copy offsite into your Dropbox account. For this reason a progress report is displayed showing closedown backup progress, as illustrated below.

a fresh backup is ready to run

nb: each fresh backup copy will just overwrite the last backup, until you have completed the following step, to create and configure your backup repository.

Default backup location

By default the interim backup file is named backup_db.zip, and is stored AlbumPlays’ working directory.
collapse

 

Backups are compacted to minimise storage requirements, but are not encrypted, as I see no significant privacy considerations. Contact me if you disagree.

My advice is to set your backup cycle to something like weekly or monthly. Last.fm will already be collecting and storing your fresh track plays. If you ever need to return your databases to a backup copy, it doesn’t really need to be too current a copy, because a Get & Approve cycle or two will restore all of your recent plays. …. The most important thing is that you do have a synchronised AlbumPlays & MediaMonkey backup pair. It is also good, as a secodary consideration, if they are reasonably recent, as this will reduce the loss of any recent re-tagging you have performed, and reduce complications when re-importing scrobbles from Last.fm, due to factors such as Last.fm “corrections” to your scrobble submissions.

The following example configuration would trigger backups on a weekly cycle.

[gui]
_backup_cycle = 7  

Configuration: step two: configure your backup repository

By default you will have no backup repository, meaning that each new backup will just overwrite the previous one.

You create your backup repository via the Edit|ApplicationBackupScheme menu item, which allows you to configure your backup scheme.

menu option to configure your back repository

Configure your backup scheme with the following three settings:

Levels
How many cycles do you want within your backup scheme?
eg. you could have a cycle containing weekly backups, and another independent cycle containing monthly backups; this would be 2 cycles (aka levels)
Slots
How many backup copies should be held at each level
eg. you may elect to keep the latest 4 of the weekly backups, and the latest 6 at the monthly level
Location
Where is each level to be located?
Each level may be stored at a separate location.
The locations may be on your PC, or elsewhere on your LAN, or offsite at a free Dropbox account.
  • configure your backup scheme (click to expand)

It is quite straight forward to design your own configuration scheme, but you may prefer to just adopt one of the following three recipes, otherwise open the fourth section for documentation showing how to design your own scheme.

Recipe #1: minimal; a rotating set of monthly backup copies, going back for six months

This recipe will maintain a series of monthly backups, going back for least 6 months.

Set the backup cycle to monthly, with the following change to the configuration file.

[gui]
_backup_cycle = 30

And then use the Application Backup Scheme configuration facility (Edit|ApplicationBackupScheme) to make the following changes:

backup recipe: minimal (click to expand)

  • Levels – set to 1, press Update (or F3), and then return to make the following updates
  • slots – set to 7, so that on the day of any backup, you will have that backup copy, plus the 6 preceding monthly backups
  • Location – set to “lan”

The following configuration setting allows you to tailor the location for your backup repository to a directory of your choosing, as described here.

[gui]
_bu_lan_path = ~\My Documents\AlbumPlays\Backups

Otherwise the the backups will be stored in the default repository location, which is documented towards the end of the “Location” section found here

Alternatively you may set the location offsite to your Dropbox account. You do this by setting the location to dbx rather than lan. You will also need to authorise AlbumPlays to store a folder into your Dropbox account, as described here.


collapse

Recipe #2: extensive; keep a month's worth of weekly copies, as well as monthly copies for 6 months

This recipe saves copies going back 6 months, and has all weekly snapshots for the last month:

  • a rotating cycle of the 4 most recent weekly backup copies
  • and separate set of the 7 most recent monthly copies
  • ie, 11 separate backups, spaced across the preceding 6 months, potentially stored on two computers

Set the backup cycle to weekly, with the following change to the configuration file.

[gui]
_backup_cycle = 7

And then use the Application Backup Scheme configuration facility (Edit|ApplicationBackupScheme) to make the following changes:

backup recipe: extensive (click to expand)

  • Levels – set to 2, press Update (or F3), and then return to make the following updates
Level settings Level 1 Level 2
slots set to 5, so that on the day of any backup, you will have that backup copy, plus the 4 preceding weekly backups set to 7, so that on the day of any backup, you will have that backup copy, plus the 6 preceding monthly backup
location set to “lan” set to “lan2”

Then tailor the locations for your backup repository to a directory of your choosing, as described here.

It is preferable that the levels be on a separate disks or computers.

[gui]
_bu_lan_path = ~\My Documents\AlbumPlays\Backups_weekly
_bu_lan_path2 = d:\AlbumPlays\Backups_monthly
or  _bu_lan_path2 = //your_NAS/your_share/

If you make no location override configuration, the backups will be stored in the default repository locations, as documented towards the end of the “Location” section found here

Alternatively you may set the location for level 2 offsite, to your Dropbox account. You do this by setting the location to dbx rather than lan2. You will also need to authorise AlbumPlays to store a folder into your Dropbox account, as described here.


collapse

Recipe #3: comprehensive; keep a month's worth of weekly copies, plus an summarised archive going back two years, stored in multiple locations

This recipe has recent weekly snapshots, and covers 2 years:

  • a rotating cycle of the 4 most recent weekly backup copies
  • and separate set of the 3 most recent monthly copies
  • and separate set of the 9 most recent quarterly copies
  • ie, 16 separate backups, spaced across the preceding 2 years, potentially stored on three computers

Set the backup cycle to weekly, with the following change to the configuration file.

[gui]
_backup_cycle = 7

And then use the Application Backup Scheme configuration facility (Edit|ApplicationBackupScheme) to make the following changes:

backup recipe: comprehensive (click to expand)

  • Levels – set to 3, press Update (or F3), and then return to make the following updates
Level settings Level 1 Level 2 Level 3
slots set to 4, so that you will have the four most recent weekly snapshots set to 3, so that you will have the three most recent monthly snapshots set to 9, so that on the day of any quarterly backup, you will have that backup copy, plus the 8 preceding quarterly backups
location set to “lan” set to “lan2” set to “dbx”, to cause quarterly backups to be transferred offsite to Dropbox servers
or to “lan3” if you do not want to use Dropbox

Then tailor the locations for your backup repository to a directories of your choosing, as described here.

It is optional, but preferable, that the levels be on a separate disks or computers.

[gui]
_bu_lan_path = ~\My Documents\AlbumPlays\Backups_weekly
_bu_lan_path2 = d:\AlbumPlays\Backups_monthly
or  _bu_lan_path2 = //your_NAS/your_share/        if you have a NAS
_bu_lan_path3 = //your_NAS/your_share/Backup_quarterly   .... if you don't want to use Dropbox, ie. set it some other location 

If you make no location override configuration, the backups will be stored in the default repository locations, as documented towards the end of the “Location” section found here

If you chose to use Dropbox you also need to authorise AlbumPlays to store a folder into your Dropbox account, as described here.

collapse

Backup scheme configuration details

AlbumPlays is programmed to enable a grandfather-father-son style backup scheme as described here. You configure your scheme by specifying how many levels, and the locations & number of slots for each level. You make these configurations using the facility discussed above.

backup recipe: comprehensive (click to expand)

Levels
How many cycles do you want within your backup scheme?
You may have 1, 2 or 3 levels.
An example would be a grandfather-father-son scheme, in which case you would need 3 levels:
1. The “son” level, which could hold, for example, weekly backups
2. and a “father” level: which could hold monthly backups
3. and a “grandfather level, which could hold quarterly backups
nb: if you are setting up your backup repository for the 1st time, you will need to set the number of levels, then press F3 or Update, and then return, to set slots and locations for each level.
Slots
How many backup copies should be held at each level
This is best explained by an example. If you wanted a scheme which:
* stored 4 weekly backup copies
* also 3 separate monthly copies
* and 9 quarterly copies
* ie, 15 separate backups, spaced over the preceding 24 months
This scheme would be achieved by:
firstly configuring:
1. AlbumPlays to take a fresh backup each 7 days as described previously
2. and then set the number of Levels to 3
and then set the Slots for the 3 levels as follows:
1. the “son” would be configured to have 4 slots, ie. one slot for each of the 4 weeks in the month
nb: each time that the 1st slot of any level is written|overwritten, the new backup copy is also propagated up to the next level (eg. son -> father in this case). … So what is held at any level, is in part defined by the number of slots in the preceding level. eg: if the backup cycle was weekly, and the first level had 4 slots, this would mean that the second level contained “monthly” backups (4 * 1 week = a month)
2. the “father” would have 3 slots; one slot for each of the 3 months in a quarter
3. the “grandfather” would have 9 slots, to cover a duration of at least 2 years (ie. the current backup, plus at least 8 quarters of history)
Location

Where is each level to be located?
You may specify up to 3 onsite locations (either on your PC or elsewhere on your local network), and one optional offsite location (at Dropbox). For example, the son level could be on your PC, the “father” level” on your NAS, and the “grandfather” level could be at Dropbox.
You may specify only 3 locations in total.

You identify these locations by using the following tokens (as illustrated on the above illustration):
* ‘lan’, ‘lan2’ or ‘lan3’ refer to the “local” locations (your PC or elsewhere on your LAN)
* ‘dbx’ refers to the offsite location (at Dropbox); it is optional, and if used, there can only be one off-site location, and it must be used on the last last location

You may override the paths for the local locations via configuration file settings such as bu_lan_path, as described here
Otherwise the default level locations will be in separate directories, which will created as required, beneath that directory which you specified in your _nas_path configuration option,  
* or if you made no specification for _nas_path, they will be stored in directories beneath AlbumPlay’s working directory
Setup for the optional offsite location (Dropbox) is further covered here

collapse

 

Running on-demand backups

As described above application backups are run automatically when you close down AlbumPlays, according to your backup cycle configuration.

You may also trigger an out of cycle backups via the “Set Options” button on AlbumPlays’ front panel.

One-time options button

Select the “Force an application backup” radio button, Press OK, and then close down AlbumPlays to trigger the backup.

Trigger an on-demand backup

An on-demand backup will reset the backup cycle for future backups. An example would be, if your backup cycle is every 7 days, and it was happening every Monday. If you triggered an on-demand backup on a Wednesday, the next backup would be in another 7 days, meaning that your scheduled backups would move from Mondays to Wednesdays.

Offsite backup copies; Dropbox

AlbumPlays uses Dropbox to implement it’s solution for offsite storage of backup copies. Use of Dropbox is optional.

Dropbox offers free accounts for small scale personal use such as this.

Once you have your own Dropbox account you will need to authorise the AlbumPlays app to your Dropbox account. AlbumPlays is given only restricted rights, as will be clearly described by Dropbox as you grant access. AlbumPlays will only be given access to a folder named AlbumPlays, which will be created inside an named Apps. You do not need to give your Dropbox password to AlbumPlays.

Here is a useful article explaining security considerations when granting access to third-party access to your online accounts, it also explains how to revoke access.

Button to request authorisation

Request authorisation from Dropbox via the “Authorisation” button on the “Configure application backup scheme” panel. … If you receive an error message saying that you need to install Python’s support library for Dropbox, follow the error message’s on-screen instructions (or see footnote #1).

The Authorisation button will open a new panel, explaning the authorisation procedure.

Button to request authorisation

When you press the “Step 1” button, Dropbox will open in a new browser. You need to sign into your Dropbox account, and then press their Allow button. They will issue an authority token code for use by AlbumPlays. You need to cut and paste that authority code into the AlbumPlays screen containing the on-screen instructions, and then press it’s “Stage 2” button. You only need to do this once. AlbumPlays will save a copy of the authority code, allowing it to automatically gain access into Dropbox whenever a backup copy needs to be elevated into the Dropbox level of your backup repository.

Dropbox authorisation process

You designate a level in your backup repository as being off-site by setting the level’s location to “dbx” as described here, (see level 3 in the following illustration).

backup recipe: comprehensive (click to expand)

Only one level in your backup repository may be offsite, and it must be the last level; eg. AlbumPlays is able to elevate a backup from an onsite level, to the offsite level, but there is no facility for it to then elevate that backup copy up to a subsequent onsite level.

Verification of backups

It is important that you verify that AlbumPlays is creating functional backups. You should do a “fire drill”, by restoring both the MediaMonkey and AlbumPlays databases, to make sure that the backups are usable.

If you don’t know how to do this, you should contact me.


FootNotes:


  1. Install Dropbox support
    If you wish to place one of your application backup repositories onto Dropbox you will need to have installed the Python support library for Dropbox.

    This is simple to achieve:

    1. Close AlbumPlays
    2. Rerun the AlbumPlays install program mentioned here … nb. re-installation will not affect your database, nor will it affect your AlbumPlays configuration
    3. On the Select Components panel, ask for a Full Installation
    4. On the Additional Tasks panel, check the connection to Dropbox option
    5. Complete the install