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
- Step one: start making backups
- Step two: configure your backup repository
- Running on-demand backups
- Offsite backup copies; Dropbox
- Important!: Verification of backups
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.
- 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.
- 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.
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.
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.
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.
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.
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:
- 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
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:
- 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
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:
- 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
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.
- 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 locationYou 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.
Select the “Force an application backup” radio button, Press OK, and then close down AlbumPlays to trigger the 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.
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.
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.
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).
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:
-
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:
- Close AlbumPlays
- Rerun the AlbumPlays install program mentioned here … nb. re-installation will not affect your database, nor will it affect your AlbumPlays configuration
- On the Select Components panel, ask for a Full Installation
- On the Additional Tasks panel, check the connection to Dropbox option
- Complete the install