New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offer possibility to get consistent backup (regarding applications) #81
Comments
Currently I use rear-1.10.0 (on a SUSE Linux Enterprise 11 SP1 system) and there I have /usr/share/rear/backup/readme which reads: 00-09: initialization Accordingly I have in particular those files /usr/share/rear/backup/NETFS/GNU/Linux/30_stop_selinux.sh /usr/share/rear/backup/NETFS/GNU/Linux/60_start_selinux.sh I.e. there is already something implemented at the right time to stop something before backup and re-start it after backup. I suggest to only enhance this as follows: Provide two directories where executables (usually bash scripts) can be placed by the system admin which are run before the backup and after the backup. Why directories? This way the system admin (or even several system admins) can maintain separated executables to stop and re-start Separated scripts for separated services should be run by default simultaneously to speed up the overall time untill all services are stopped and re-started. If different services depend on each other the system admin must implement in his scripts that one waits until another one has completed. Perhaps ReaR could provide functionality to enforce running them one after the other only if the executable file names have leading two-digit numbers and all executables with none or same numbers are launched simultaneously. It may take a longer time until a service can be stopped in a reasonable/friendly way in the running system. Examples:
In such cases it would be good if the scripts for the printing and mail service would run by default simultaneously (and also wait simultaneosly until the 200 pages print job finished and the huge mail was completely received). I think it belongs to the system admin to make appropriate scripts to stop and re-start his particular services in a way which is reasonable in his particular environment. In particular only the system admin could know how long to wait for a service to complete its current active tasks before the service is forced to stop. Think about an active printing 200 pages job at 3 o'clock in the night where the printer runs out of paper at page 190. I think all what ReaR should provide are those directories and the functionality to run all executables therein but not the actual executables therein. Perhaps ReaR might provide example scripts as documentation but no actual executables in those directories. |
How about this approach? We introduce a new directory The big advantages I see, is that we would be able to leverage init-script logic, like start-stop dependencies, start-stop-status shell-syntax and such, while keeping all these complexities out of rear. I also believe, that this would be a very intuitive abstraction layer to the user, making it easy to add and remove backup-safe services for any particular execution of rear. Writing a separate rear script for every service one wants to be backup-safe would be (in many cases) reduced to Additionally we could limit rear to only call start/stop on files in |
Let me clarify the two main opinions in the development team.
Both views make sense. Nothing has been decided, however one thing is clear. At this point this is not a priority, so unless someone is doing the implementation or sponsoring an implementation this is unlikely to happen in the short term. However, the ability to hook scripts into different parts of Rear is more generally useful and is therefor more likely to see the light of day. But that doesn't mean we cannot have both at some point. |
Regarding SysVinit scripts and "leverage init-script logic" and any kind of "abstraction layer": Nowadays there is no longer only SysVinit but also systemd so that there is no longer a single generic way how to stop and re-start services. This means it becomes complicated if Rear would try to provide some kind of ready-to-use functionality to stop and re-start services. |
I agree with statement of @jsmeix - it is not the task of rear to stop/start services. |
When making backups using Rear, we need to make sure that running applications or deamons write consistent data out to the file system. This is impossible, except when stopping services this can be guaranteed in all cases.
For this we would like to add the capability to stop and start services before and after running the backup.
We need to make sure that:
The implementation would use an array as a list of services to stop/start, and by default it would be empty (so this functionality is effectively disabled).
It is the task of the system administrator to decide what applications require this and what the effects are of stopping the service and the resulting downtime.
The text was updated successfully, but these errors were encountered: