Backup scripts are a bit complicated

IMHO, they are a bit complicated.

What we do in IndieHosters is that each package as a pre-backup script which is basically doing a dump of the database in the same directory. Then the infrastructure which is responsible to maintain backups is going though every app folder, run this pre-backup script, and use duplicity to save the diff on a distant server.
In the case of Yunohost, it would be locally obviously.

So I have various questions:

  • what would you think of a PR to use this behaviour?
    the huge win is that, it usually boils down to mysql dump, so the script will be the same for almost every lamp apps.
    another win will be that our backup archive will be compatible with IndieHosters \o/

  • At IndeiHosters, we were thinking to sell services for yunohost users, and one of them could be to offer distant backup services.
    Is there a way for the user to install “system app”. In this case the system app would override or superseed the official system backup app.

This is just a discussion in an attempt to merge IndieHosters packaging system with yunohost :slight_smile:

IMO the yunohost backup can’t be so simple because yunohost app are not so simple.

For a basic php-mysql app, we have to save:

  • app source (and possibly configs files and/or data)
  • mysql dump
  • nginx conf
  • php-fpm conf (not all apps use a dedicated php pool but it’s a good practice)
  • yunohost app config (not in the backup script since yunohost save that automatically during a backup)

And sometime there is also other data that are not stored in the same directory (ex: owncloud).

So having a mysql dump at the root of the webapp (which btw seems not to be a good security practice) will not change anything. I wrote some backup/restore scripts the other day for my apps and I think they are simple, here is an exemple https://github.com/mbugeia/kanboard_ynh/blob/master/scripts/backup it’s just copying the right files to a logic place in a backup directory so they can be easily exploited by the restore script.

About your first question, we discuss this point (about a default backup script), there was different point of view about this idea. The cons arguments was that not all apps are based on nginx and mysql. You can have apps based on reddit or on ldap, you can install an app to setup cron more easily, install dmarc or change the ssh port…
The pro argument was that there was a lot of MySQL/PHP apps build exactly with the same way. But there is also the question of right on directory, php config etc…

Personnaly, I think backup script are simple. But restore script is more complicated and we need to find a better way because there are lot of redundant scripts between upgrade, install and restore scripts.

About your second question, you can add module to the yunohost cli/api. There is an (old) example here:

NB: in this app some routes are added to the api to be able to offer a subscription page on the yunohost instance.

However, currently, it’s not possible to add module to the web admin, there is an old PR (never finished) on the repo about that:

Ok, sorry, but I think I don’t know enough yunohost architecture to comment.

On my infra, I like/try to apply single responsibility principle.
So an app running on a domain is all contained in one folder (the web root is a folder inside this folder).
When I start an app, this app registers itself.
The tls offloader (in my case HAproxy instead of nginx) will discover it and apply the configuration.
(more on discovery/registration pattern)

And so the backup, it is one process that is looping though all apps and runs the “backup” script in each directory (usually just a dump of the db - not in the webroot :slight_smile: ) and save the diff on a distant server.

So I find it “complicated” as each backup script has to take care of a lot of steps.
I find my way “simpler” but well, we have a different infra/architecture/organization.

(About the service, I’ll open an other thread when needed, thanks for the answer)

Are you interested in working together to make it “simpler”? I can PR, but I need some confirmation before as it would be some work. And is it the right place to discuss it?
I do it because I want the packages/backups compatible from IndieHosters with yunohost.
But I think yunohost community could benefit from that also to have more applications supporting backup/restore capability.

Let me know!

Sorry Pierre I was supposed to package an IndieHoster app in YNH as a proof-of-concept but other priorities took over… I’ll try to do it sometime on a VM with your indiepaas

If you say it’s similar to Docker it shouldn’t be too complex

But I agree it would be great to have backup/restore compatible IndiePaas-YNH
The other problem I see with YNH is that the backup/restore scripts cannot be launched on single users (to move just one user). See https://dev.yunohost.org/issues/148