Backup and restore custom paths

In short

It should be an easier way to backup and restore custom paths edited or added by hand by an admin.

The current "official" way to do it

https://yunohost.org/en/backup/include_exclude_files

However, this method is not really easy, the admin need to be confident in editing 2 bash scripts, a lot of errors can be made, etc.

A list of example of things made manually we probably want to backup and restore (or not)

A cron task for an app
A general fail2ban rules to ban some web bots
/root/.ssh
/opt/custom_apps (A custom service manually installed )
/usr/local/bin/
/etc/skel/
/var/www/nextcloud/core/skeleton/
/etc/yunohost/hooks.d/post_app_upgrade/custom (custom hook to reapply some change after upgrade)
/etc/sysctl.d/custom.conf
...

Better solutions

Solution A: One or several config files into /etc/yunohost

We could imagine add a simple /etc/yunohost/extra_paths_to_backup and add this at the end of hooks/backup/50-conf_manually_modified_files

# Allow to backup in more a list of extra paths defined by the admin
if [[ -e /etc/yunohost/extra_paths_to_backup ]]; then
    ynh_backup --src_path="/etc/yunohost/extra_paths_to_backup"

    for file in $(cat /etc/yunohost/extra_paths_to_backup); do
        ynh_backup --src_path="$file"
    done
fi

And this at the end of hooks/restore/50-conf_manually_modified_files

# Restore custom paths listed by the admin
if [[ -e ./extra_paths_to_backup ]]; then
    ynh_restore_file --origin_path="/etc/yunohost/extra_paths_to_backup"

    for file in $(cat ./extra_paths_to_backup); do
        ynh_restore_file --src_path="$file"
    done
fi

However, several questions comes:

What if users want to backup "extra data paths", we should not save it inside conf part. So should we add /etc/yunohost/extra_conf_to_backup and /etc/yunohost/extra_data_to_backup.
Should we add a question in general config panel in order to edit those files ? or something like yunohost backup paths list|remove <path>|add conf <path> ?
Do we want to separate several custom paths into category in order to restore it selectively ? (like in the official tuto)
Should we support to "attach" those paths to an entity (app, domain, user, nothing) ? If yes, we probably should store the paths list into related /etc/yunohost/apps or /etc/yunohost/domains...
Should we adopt a yaml structure like /etc/yunohost/extra_paths_to_backup.yml and put conf and data inside it even it's more difficult to edit ? Are we ok with the idea some conf files in /etc/yunohost can be manually edited and some other are not really made for it ?

Solution B: A "Custom Backup" app

A totally different and easier approach is to create a "Custom Backup" app, in which backup and restore script is filled with a config panel.

The user can install one or several if it's needed to separate things.

It's in the spirit of popular apps "My Webapp" and "Redirect"...

Extra benefits:

Instance documentation

This feature could also help to reference manual change on an instance. It's a nice feature for instance manage by several admin (or admin who managed a lot of instances...).

Use case detection

We could suggest to share/publish easily some custom files in order to share with others (or just yunoteam) some usecases.

YunoHost / issues