I’m a little confused with the helper
ynh_backup and the “is_big” argument.
By reading the code, it seems that we should set a setting for the app that is called “do_not_backup_data”?
What happened to BACKUP_CORE_ONLY?
I tried to give a look to other apps but I did not see any doing the same as another, and the doc is not very talkative…
Thanks for your lights on this topic!
Indeed, not a clear part of the backup.
Many modifications happened on this matter.
We were, a not so long time ago, using
backup_core_only as a config set into the settings.yml of an app.
But it was source of many issues when the backup wasn’t properly done. We were ending up with the setting still in the config and still used for all backup. Even when not willing to.
So, here the current status of that, which is quite stable.
An user can set the setting
do_not_backup_data to 1 into the config of an app to prevent data to be backed up by the backup script at any moment.
This is an action from an user, which will affect all backups made for the app.
(Side note, this should be into a config-panel)
Otherwise, the main use case of creating a backup without data is the backup made before the upgrade of the app.
ynh_backup_before_upgrade does set the environment variable
BACKUP_CORE_ONLY to 1 when doing the backup.
BACKUP_CORE_ONLY=1 does the same thing as
do_not_backup_data, but it affects only the current shell. So this variable can be used to force a backup without data, but does not affect subsequent backup afterward.
Aside of the helper itself, this variable is useful for personal backup scripts.
- Finally, the argument
is_big is to be used with the helper
ynh_backup to specify into your app backup script, which part of the backup is considered as potentially big data an user could not want to backup.
Be careful though that, as this part of your app may not be backed up, you should not remove it either in your remove script.
Otherwise, a failed upgrade will remove the data and restore the app without it ! Not cool !
Thanks a lot for the clarification!
So, from a packager perspective, I should not initialize
do_not_backup_data as 1 in order not to save these data but rather provide a config-panel option to change it for the user?
You should not set
do_not_backup_data, otherwise you’re going to force all your user to not backup their data.
The only thing you have to consider is actually to use
--is_big at the right place. And to be careful with it in your remove script.
To provide a config_panel option is not mandatory, but it would be so easier for your users to do that from the admin panel that it would be really to bad to not add it
EDIT: I wasn’t sure but indeed.
In your restore script, as the backup with --is_big is optional, you need to use
--not_mandatory for the restoration of this part.
That way, if the data to restore does not exist into the backup, it won’t fail.
mmmmok, stupid question then : I installed etherpad which has config_panel.toml and action.toml to understand how these are working…
But where am I supposed to find these options? I don’t see anything in the graphical UI? Are they command line options?