@davidep another test, all ok for me…
i know that now there is fantastic button to download backup config, but what do you think to add in the Backup configuration tab a check button like: copy latest backup config in the same destination folder of backup-data?
so we can have an automatic external backup of data and configuration…
and yes, i know i’m really lazy
I think that already happens when backup-data runs! I expect also the entire history is included in backup-data.
My plans for the future are merge the “Backup (data) and Backup (configuration)” pages together and allow restore of data from the UI, too. But this is another discussion…
yes, is inside the backup, but i think it could be useful to have the backup-config.tar.xz visible directly on the backup folder, as single file. So if i need to restore a ns7 i could
1 install ns7
2 restore config (taken from my folder on nas or webdav)
3 restore full or part of data (the configuration settings was restored in point 2)
or
i could also simply take the config backup from nas to create a clone of installed ns7
and yes i can also use the download button and store locally the backups
in any case it will be really useful when creating testing VM, tnx
It already works like that in the current version! I was talking about it with @giacomo this morning
If backup-config.tar.xz does not exist in /var/lib/nethserver/backup/ dir, the restore-config command attempts to extract it from the backup-data.
You need to configure the backup-data destination, though…
We could allow this operation from UI: kinda “restore configuration from backup data set”
We could add an action to “post-backup-data” event that copies the configuration backup to the mounted backup device.
Edit: @dz00te, do you think the full history would be useful (/var/lib/nethserver/backup/history/ directory and its contents)? Or the current archive only is enough (/var/lib/nethserver/backup/backup-config.tar.xz file)?
for my use case i think the current archive is enough, but honestly i don’t know if there are other scenarios where history might be useful… if someone else is interested, it’s time to talk
Little feature request: can a description be edited after the end of the backup?
Also: config let choose how many sets you want to retain, but not timing…
What do you think if I split this discussion? So I can move it into the testing category, close the old one and avoid people to read through several posts.
I wouldn’t implement a double condition, too complex!
If I set a rule like “clean up configuration backups older than T”, it can conflict with “keep up to N configuration backups”. If N is big enough, it is surely a super-set of T.
I agree with Davide.
Adding a time based removal will not be good.
Let’s say that you set yor removal limit to be 6 months.
What will happen if you do not check the server in 7 ?
I think that number of backups to be saved in history is the best approach.
The one feature that i wanted to add but did not complete it, was to be able to send the backup over email.
The configuration backup runs every day within cron.daily, that means a random time betwen 3 AM and 22PM.
However, if backup-data is enabled, the configuration backup runs just before the backup-data runs. In other words it obeys the backup-data scheduled time.
This is just an implementation detail, please do not consider it a feature at all
@davidep I think that a really good feature will be the ability to export / restore selective config sections.
For example restore section from backup only for DHCP and networks and firewall.
Something like select a backup to be restored and have two options: Restore -all or Restore - specific.
And when you select Restore - specific you are presented with a list with checkboxes for each section.
The current backup implementation is designed for disaster recovery scenario. We can push it beyond this, like we’ve done for ns6 upgrade but it’s a risk and it’s very complex.
Modules selection is a possible enhancement, because we have the underlying data required for an implementation.
However resetting unique items, such as selectively restore/merge some parts is much more difficult. We need to merge different versions of the configuration database. Designing an UI for this task is even more difficult IMO.