Closed yunohost-bot closed 1 year ago
yunohost-bot
commented
8 years ago Author: julienmalik
Actually the same idea extends to the backup of raw file. I feel our core backup system should simply save all /etc , /var/www , /opt , /var/log , /var/spool/cron , /root , /home
yunohost-bot
commented
8 years ago Author: julienmalik
yunohost-bot
commented
8 years ago Author: jocelyn
I think it's fair enough to backup all the bases "just in case", even if it does not replace a propper app backup.
I would see it as :
yunohost backupyunohost backupyunohost backup but arround and documented, just in caseI think the ideal case is still when an app backups explicitly its own db. So better not to restore automatically the "all bases" backup, as it could mess up with per-app backup.
yunohost-bot
commented
8 years ago Author: jerome
I don't share the same view, as we already discussed... And that's why it was implemented like this.
The backup/restore system has been designed to be flexible enough to easily add things to save which YunoHost do not manage. We decided - unless I am mistaken, and as other YunoHost parts - to not think about and try to handle each "unexpected" user behavior/operation.
Firstly, it adds more responsibility to do and manage on our side: properly save/restore all MySQL databases - should we also save all other databases backends by the way? - and you also talk about all main system files... So, we will have to do more - even if some services that we currently save/restore still have bugs and could be improved - and I guess better, otherwise, why should we save the whole system if some things does not restore well and results in a broken system... That's why I think we should focus on what YunoHost manage - services and files, do not try to manage everything in the whole world and keep it as simple as possible, there is already a lot of things to do.
Moreover, as suggested by the foregoing, I think it removes some serious responsibilities from users. We are about to say to them: "Don't worry, you can do everything you want on your server - i.e. install not-working/finished app - also outside of YunoHost, we will take care of save/restore everything for you!". In other quick words, and more generally, do we want to do as Micro$oft - making things simple as stupid just by clicking, without any "computing" and knowledge behind? I really prefer to help to build a decentralized world of conscious people - even if they have just few computing skills, so long as there are mutual aid and documentation - and warn them about what they have to take care by their own thanks to open and shared knowledges. I think it's acting in user's interests, and also in ours.
Finally, to react to your personal situation and feelings, I understand it. But, I think it should be better to share hooks/documentation for that instead - i.e. in a dedicated category in the forum. Also, as raised, what will be the plan to manage the restoration? I think that if it's just for backup, and users have to restore some personal databases - or apps without backup/restore scripts - they WILL have to make computing and manipulate the command-line interface! And also too, if they think we also backup this and we not, they will be just mooooore frustrated... :) But, that's my view.
yunohost-bot
commented
8 years ago Author: jocelyn
Ok, points of view have been expressed, no consensus at the moment.
On a technical note, to be more accurate on my proposition, (widely based on Julien's) : the backup of all databases "just in case" should/may be in a different backup hook.
yunohost-bot
commented
8 years ago Author: jerome
the backup of all databases "just in case" should/may be in a different backup hook
Yes, if it has to be implemented, of course.
Another issue - from my point of view - with what you're purposing, is that it will make backup "bigger" - more in content than in size, even if some software may have a big database (>100MB)... And, as it's not possible to disable widely system hooks yet - except from passing explicitly a list of hooks to execute, which is really frustrating - you will impose this to everybody.
yunohost-bot
commented
8 years ago Author: Bram
alexAubin
commented
1 year ago Closing because the issue has been opened for 6 years and I don't see a strong argument for this
Imho the current backup system is already good enough for the nominal use case, and then there's the whole question of "entire fs snapshots" or making it easier to create custom backup hooks maybe
Original Redmine Issue: 239
Author Name: julienmalik
For the sake of "security", the core mysql backup hook could easily be extended to simply dump&save ALL databases.
Currently we delegate this work to apps backup script, but :
I have not yet thought through how to properly handle the potential conflicts during restore : should the core script restore all db ? or still leave the restore operation to apps ? I'm just saying that having that somewhere in the backup archive is already a good step forward for security. This does not cost a lot of extra space, but can provide a simple backup of VERY valuable information, so that in case things go very bad, users still have their data somewhere, and a manual restoration is possible. Losing data definitively is the sooooo frustrating !
Personally this is how I implemented my own ynh backup : I don't want to think too much nor wait for apps being ready : I just save a full mysql dump, and the whole content of /var/www and /opt. And I'm pretty confident that if things goes really bad (server crash), I could bring back to life most stuff I had running, at least manually, even if almost no installed apps implement backup.