Please add an alternative backup mode that is compatible with the incremental backups. For incremental backups i use Restic. I created a Restic repository for the Diarium backups, but just as i expected the Diarum backup system is simply not compatible with the incremental backups.
Unlike the regular backups, the incremental backups do not store each and every single backup in full size. The beauty of the incremental backups is the fact that they can deduplicate data and they do not store any unnecessary copies of the same file. Restic can recognize if a file added during a new backup snapshot was already added with a previous snapshot. If the file already exists in the backup repository then it will not be stored again. In such a case the Restic will simply make a note that this file already exists and it is used by two different backups.
The problem with the Diarium backup is the fact that the backup file is an SQLite database. This method of backup is reliable and simple, but it has some serious issues. All of the attachments in the diary are embedded into the backup file and because of this the incremental backup systems cannot effectively deduplicate the files across different backup snapshots.
For example. I made a backup snapshot with Restic. Afterwards, i deleted several attachments from my diary and made another backup snapshot. In the second backup some data was deleted and no new data was added, so in theory, a new snapshot size should be negligible. In practice, however, such backup snapshots are saved in full size, without any data deduplication at all. All backup data is duplicated and is saved again. This is literally just a waste of space and it severely limits how often i can make a backup of my Diary.
I know that the Diarium supports data export. With the data export all attachments are exported as separate files. And yes, that does work properly with incremental backups. This is pretty much what i want, but the problem is that such exported data cannot be reimported back into the Diarum. And that pretty much defeats the whole point of a backup.
Please add an alternative backup mode. I think that it should work something like this:
- User selects where to put the backup file
- Diarium exports the SQLite database as a backup file, just like it does right now.
- A new folder for attachments is created in the same folder as the backup file
- All of the attachments are exported from the Diary into the new attachments folder
- The attachment data in the exported SQLite database backup is truncated. The database keeps the records and information about the attachments, but the data of the attachments itself is deleted
- The SQLite database is vacuumed to reduce the backup file to a minimum
With this method all attachments are basically will be kept separate from the SQLite database itself. The restoration of such a backup will work the same way as a regular one, but there will be an extra step. During the extra restoration step all of the attachment data will be loaded from the attachments folder back into the database.
As such, the resulting backup will be in the form of a very small SQLite database and a bunch of attachments located in a separate folder. This form will be ideal for the incremental backup.
Diarium version: 3.1.44.0
OS + version: Windows and Android
