Automation of the Yunohost official Backup tool

Just another post on the same topic…

After reading @Walsonde ‘s post on the topic and others’ nice contributions to the thread. I realised I need to automate and improve my use of the Yunohost built-in backup tool, beyond VM snapshots or other external tools.

I see three possible solutions.

I have tested none of them.

I like the idea of using Archivist as it is an app in the Yunohost repo.

@Nido and @csolisr , why did you go for your own script when there is Archivist?
What do you think is wrong or missing on Archivist?

Thank you both.

Haven’t tested it yet, but csolisr’s solutions seems ideal to me, it’d be nice if it could be officially integrated into Yunohost or have it available as an app.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Sorry for not replying on time to the original post by @peer .

@Nido and @csolisr , why did you go for your own script when there is Archivist?

Back in the day, Archivist was having some odd issues to upgrade on my machine (especially since we were on the transition between Debian Bullseye and Bookworm). And on top of that, there were some issues with incomplete failed backups that nonetheless overwrote the original ones. So, in the meanwhile, I decided to just replicate the core parts of the Archivist script so I didn’t depend on a YNH app.

What do you think is wrong or missing on Archivist?

First, during the transition to Bookworm, I was having problems installing and upgrading Archivist itself. This was particularly vital because I was beta-testing the Bookworm version of YunoHost, so I couldn’t rely on Archivist as my sole backup solution.

Second, Archivist limits the amount of backups by the total size, not by the amount of existing backups, so in practice, we could not have rolling backups. This was particularly important to me because I have daily backups, and so I could lose the last working version of an app if I couldn’t roll back more than one day in the past.

Third, Archivist has the tendency of overwriting backups even if there was a partial error - for example, with Friendica, it sometimes fails in backing up the pictures cache but has no problem making a backup of the database. So, it compresses a mostly empty file that contains only the database dump, and overwrites the old one.

Fourth, Archivist is slow for a very important reason: in order to determine whether the backup changed or not, it does the backup process twice. First, to check whether the backup is identical to the last existing one, and second, to make and store the actual backup. While I understand why is this being done, it’s wasteful to make two full dumps of a large database if they’ll be essentially identical (my Friendica database uses about 50-60 GB, and each dump takes over an hour).

Thank you both.

You’re welcome!

Haven’t tested it yet, but csolisr’s solutions seems ideal to me, it’d be nice if it could be officially integrated into Yunohost or have it available as an app.

Thanks for the flattery, but my solution is meant to be a lightweight alternative to the standard Archivist. The latter one has important additions that my script is missing (e.g. being able to read a settings file in order to skip specific apps to backup, the ability to transfer data via RSync or Borg, and the ability to encrypt, even if we disregard the fact that encfs is unfortunately not secure enough for encryption anymore and should be replaced for something else down the line). If anything, I should try to work on Archivist itself in order to fix the issues I mentioned earlier.

3 Likes

Threads merged to ease the discussion. :slight_smile:

1 Like