| Both sides previous revision Previous revision | |
| softwares:giocoso:dbmenu:backupdb [2025/11/22 12:30] – hjr | softwares:giocoso:dbmenu:backupdb [2025/11/22 12:41] (current) – hjr |
|---|
| ====== Backup A Database ====== | ====== Backup A Database ====== |
| Keep in mind that most of a Giocoso music database, by design, can <em>always</em> be reconstructed from scratch by doing a Full Scan (Option 3): so long as your music files are safe on disk somewhere, you can always get Giocoso to have a fresh look at them and thereby re-create the RECORDINGS table. | Keep in mind that most of a Giocoso music database, by design, can //always// be reconstructed from scratch by doing a Full Scan (Option 3): so long as your music files are safe on disk somewhere, you can always get Giocoso to have a fresh look at them and thereby re-create the RECORDINGS table. |
| |
| But there's the rub: a Giocoso music database is more than just the RECORDINGS table: it's also the PLAYS table, storing the history of everything you've ever played with Giocoso... and that definitely <em>can't</em> be reconstructed, should it ever be lost or corrupted for some reason. Protecting your history of plays is thus a rather important thing to do on a fairly regular basis. The Database Management menu Option 6 has accordingly been provided to make taking a backup of your music database, including its previous play history cargo, as painless as possible. | But there's the rub: a Giocoso music database is more than just the RECORDINGS table: it's also the PLAYS table, storing the history of everything you've ever played with Giocoso... and that definitely //can't// be reconstructed, should it ever be lost or corrupted for some reason. Protecting your history of plays is thus a rather important thing to do on a fairly regular basis. The Database Management menu Option 6 has accordingly been provided to make taking a backup of your local music database, including its previous play history cargo, as painless as possible. |
| |
| First, you need to say <em>where</em> you want your backups saved to: take the Administration menu Option 3 to edit the configuration file. Once you've selected the database you want to work with, you'll see this: | I should mention that this option really does only work on the //local// database: backups of any remote, shared Pro database you might be using are handled in a completely different way. It is also true to say that a Pro database //is// a sort-of backup of your local system's PLAYS table. In a Pro context, every music play is recorded twice: once in the local database and then on the remote database. You could lose your local database completely... and yet the Pro database will still know what you have listened to. Nevertheless, even in a Pro context, it's a good idea not to lose your local PLAYS table... so, backing it up remains an important thing to do. |
| | |
| | Performing such backups requires that you first say //where// you want your backups saved to: take the **Administration** menu **Option 3** to edit the configuration file. Once you've selected the database you want to work with, you'll see this: |
| |
| {{ :software:giocoso:screenshot_20231106_082532.png?direct&650 |}} | {{ :software:giocoso:screenshot_20231106_082532.png?direct&650 |}} |
| {{ :software:giocoso:screenshot_20231106_100154.png?direct&650 |}} | {{ :software:giocoso:screenshot_20231106_100154.png?direct&650 |}} |
| |
| You have first to specify <em>which</em> database you want backed up: you can only backup a single database at a time, no matter how many others might exist. Just up- and down-arrow through the list until the right database is highlighted, then press the Space Bar to select that entry. An asterisk will appear in the brackets next to the database name. Press [Enter] to submit the selection when ready: nn practically no time at all, you'll see this message appear: | You have first to specify //which// database you want backed up: you can only backup a single database at a time, no matter how many others might exist. Just up- and down-arrow through the list until the right database is highlighted, then press the Space Bar to select that entry. An asterisk will appear in the brackets next to the database name. Press [Enter] to submit the selection when ready: nn practically no time at all, you'll see this message appear: |
| |
| {{ :software:giocoso:screenshot_20231106_100325.png?direct&650 |}} | {{ :software:giocoso:screenshot_20231106_100325.png?direct&650 |}} |
| Here, you see my /home/hjr folder: and the latest entry in it is a file called 'main_Classical_database...something or other'. If you compare that with the name of the database I selected to backup about three screenshots back, you'll be able to work out that the backup file created by Option 6 starts with the name of the database being backed up. The word -backup- is there, too, so that you know, er, that it's a backup of the database! Finally, a time-and-datestamp is appended to the end of the file name (so, you can tell my backup was taken at 10:03 in the morning on 6th November 2023), along with a .tar file extension. | Here, you see my /home/hjr folder: and the latest entry in it is a file called 'main_Classical_database...something or other'. If you compare that with the name of the database I selected to backup about three screenshots back, you'll be able to work out that the backup file created by Option 6 starts with the name of the database being backed up. The word -backup- is there, too, so that you know, er, that it's a backup of the database! Finally, a time-and-datestamp is appended to the end of the file name (so, you can tell my backup was taken at 10:03 in the morning on 6th November 2023), along with a .tar file extension. |
| |
| The tar extension tells you that this backup is created as a 'tape archive' -that is, as an <strong>un</strong>compressed bundle of folders and files, wrapped up into a single output file. On most Linux distros, you can right-click a tar file and say 'open in Ark' or some equivalent 'archive extractor' tool. If I do that now and click to open all the nested folders included in the tar, you'd see this: | The tar extension tells you that this backup is created as a 'tape archive' -that is, as an **un**compressed bundle of folders and files, wrapped up into a single output file. On most Linux distros, you can right-click a tar file and say 'open in Ark' or some equivalent 'archive extractor' tool. If I do that now and click to open all the nested folders included in the tar, you'd see this: |
| |
| {{ :software:giocoso:screenshot_20231106_101005.png?direct&650 |}} | {{ :software:giocoso:screenshot_20231106_101005.png?direct&650 |}} |
| Recovery from this backup would therefore consist of grabbing those three files out of the tar file and copying them manually into the 'real' $HOME/.local/share/giocoso3/db folder, over-writing anything sharing the same file names. | Recovery from this backup would therefore consist of grabbing those three files out of the tar file and copying them manually into the 'real' $HOME/.local/share/giocoso3/db folder, over-writing anything sharing the same file names. |
| |
| Since backups are <em>so</em> important to do, Giocoso provides one of its few remaining runtime switches to create them on a scheduled basis, without manual interaction. The relevant command is simply: | Since backups are //so// important to do, Giocoso provides one of its few remaining runtime switches to create them on a scheduled basis, without manual interaction. The relevant command is simply: |
| <p style="padding-left: 40px;"><span style="font-size: 10pt;"><strong><span style="font-family: 'courier new', courier, monospace;">giocoso3.sh --backup</span></strong></span></p> | |
| ...which will backup <span style="text-decoration: underline;"><strong><em>the</em> </strong></span><em><span style="text-decoration: underline;"><strong>default database</strong></span> </em>as mentioned in the Persistent Configuration file <strong>only</strong>. Backing up non-default databases is only possible using the Database Management menu Option 6. As an example, here's how I backup my primary music database on a nightly basis, using the crontab on my music PC: | giocoso3.sh --backup |
| <p style="padding-left: 40px;"><strong><span style="font-family: 'courier new', courier, monospace; font-size: 10pt;"># Backup the Giocoso Database every night at 2am </span></strong> | |
| <strong><span style="font-family: 'courier new', courier, monospace; font-size: 10pt;"># ---------------------------------------------------------------- </span></strong> | ...which will backup //**the default database**// (as specified in the Persistent Configuration file) **only**. Backing up //non-default// databases is //only// possible using the Database Management menu Option 6 interactively. As an example, here's how I backup my primary music database on a nightly basis, using the crontab on my music PC: |
| <strong><span style="font-family: 'courier new', courier, monospace; font-size: 10pt;">0 2 * * * /usr/bin/giocoso3.sh --backup</span></strong></p> | |
| Bear in mind, however, that the Giocoso database is only a file on a file system: you can perfectly well use standard file system tools to take backup copies of it at any time, without needing to use any of Giocoso's built-in backup capabilities. Here, for example, is another crontab entry I use to create remote backups of <em>all</em> my Giocoso databases in one hit: | # Backup the Giocoso Database every night at 2am |
| <p style="padding-left: 40px;"><strong><span style="font-family: 'courier new', courier, monospace; font-size: 10pt;"># Backup the Giocoso Database every Tuesday at 6pm </span></strong> | # ---------------------------------------------------------------- |
| <strong><span style="font-family: 'courier new', courier, monospace; font-size: 10pt;"># ---------------------------------------------------------------- </span></strong> | 0 2 * * * /usr/bin/giocoso3.sh --backup |
| <strong><span style="font-family: 'courier new', courier, monospace; font-size: 10pt;">0 18 * * TUE /usr/bin/rsync -avh --delete $HOME/.local/share/giocoso3/db/ hjr@remote_server:/home/hjr/Documents/GiocosoBackups</span></strong></p> | |
| ...which simply copies everything sitting in my Giocoso /db subfolder into a single folder on a remote server. The backup gets over-written every week by the newest backup, but that's OK for my purposes. Simple use of 'cp' and 'mv' could achieve similar results. The main point to make here is not that it necessarily matters <em>how</em> you backup your music database... but that you <em>should</em> back it up! Your music play history is at risk if you don't. | Bear in mind, however, that the Giocoso database is only a file on a file system: you can perfectly well use standard file system tools to take backup copies of it at any time, without needing to use any of Giocoso's built-in backup capabilities. Here, for example, is another crontab entry I use to create remote backups of //all// my Giocoso databases in one hit: |
| | |
| | # Backup the Giocoso Database every Tuesday at 6pm |
| | # ---------------------------------------------------------------- |
| | 0 18 * * TUE /usr/bin/rsync -avh --delete $HOME/.local/share/giocoso3/db/ hjr@remote_server:/home/hjr/Documents/GiocosoBackups |
| | |
| | ...which simply copies everything sitting in my Giocoso /db subfolder into a single folder on a remote server. The backup gets over-written every week by the newest backup, but that's OK for my purposes. Simple use of 'cp' and 'mv' could achieve similar results. The main point to make here is not that it necessarily matters //how// you backup your music database... but that you //__should__// back it up! Your music play history is at risk if you don't. |
| |
| ---- | ---- |