#2543 Issue closed: Feature proposal: Prevent concurrent runs of OS sw package management tools and and ReaR¶
Labels: enhancement, needs sponsorship, external tool,
no-issue-activity
jk-10 opened issue at 2020-12-12 22:59:¶
At least in Ubuntu security updates default setting is to download and
install updates automatically.
If sw upgrade is running at the same time as ReaR is running, e.g during
mkbackup or mkrescue commands,
the output of those commands can be inconsistent and might cause
failures during recovery.
Also if rear mkbackup or rear mkrescue commands are launched from cron, it is possible that user accidentally runs package management tasks when rear is running.
If the system is using LVM, consistent backups are possible with LVM snapshots but not all systems are using LVM.
My proposal is that ReaR should be capable of preventing simultaneous
run with OS sw management tools.
That means either blocking OS sw management tools (apt, yum, ...) while
rear is running or blocking rear until a running OS sw management tool
has finished.
At least in Ubuntu this can be done by getting exclusive lock on file
/var/lib/dpkg/lock.
This capability could be configured with few new variables, e.g. like this:
# If DISABLE_CONCURRENT_SW_MANAGEMENT="yes" then ReaR checks at startup whether sw package manager is running,
# if sw package manager is running then ReaR waits until sw package manager has ended.
# If sw package manager is not running then ReaR acquires exclusive lock preventing sw package manager to start
# and keeps the lock until end of ReaR operation.
# If DISABLE_CONCURRENT_SW_MANAGEMENT="no" then ReaR does not check sw package manager running status at all.
# Default setting DISABLE_CONCURRENT_SW_MANAGEMENT="no" is backward compatible
DISABLE_CONCURRENT_SW_MANAGEMENT="yes"
# TIME_LIMIT_WAIT_SW_MANAGEMENT: Number of seconds ReaR waits for the sw package manager to finish its job
# if the sw package manager is running when ReaR is started.
# If the sw package manager is still running after time limit has elapsed, then ReaR aborts its operation and exits with error status.
# If TIME_LIMIT_WAIT_SW_MANAGEMENT=0 then wait for indefinitely.
# This setting has no effect if DISABLE_CONCURRENT_SW_MANAGEMENT="no"
TIME_LIMIT_WAIT_SW_MANAGEMENT=0
gdha commented at 2021-01-08 11:08:¶
@jk-10 interesting idea and as you have given it a good though why not write a PR yourself?
jsmeix commented at 2021-02-22 15:12:¶
@jk-10
a precondition is reliable autodetection of all possible OS sw
management tools
for all Linux distributions and all their various versions where ReaR is
supported.
In general ReaR is neither a backup software nor a backup management
software
and it is not meant to be one, cf. the section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
that reads (excerpts):
ReaR only calls an external tool that does the backup
of the files during "rear mkbackup" ...
It is your task to ensure your backup is consistent ...
E.g. you may have to stop certain running programs
(e.g. whatever services or things like that) that could
change files that get included in your backup
before your backup tool is run.
Another excerpt from
https://en.opensuse.org/SDB:Disaster_Recovery
What "consistent backup" means
Consistent backup means that all files in the backup
are consistent for the user. For example assume the
user is running an application program that changes
several files simultaneously (in the simplest case
think about the user is manually changing several
files simultaneously, e.g. 'root' or a setup tool may change
several config files). When that program is running during
files backup, the backup may contain old data in some files
and new data in other files which could be an inconsistent
state. Such inconsistencies could lead to errors in that
application after such an inconsistent backup was restored
or probably even worse the application blindly continues
to operate on inconsistent data which could make the
overall state more and more inconsistent over time until
at the very end all might be completely messed up.
I.e. there are zillions of other things that could result
an inconsistent backup.
github-actions commented at 2021-04-24 02:29:¶
Stale issue message
[Export of Github issue for rear/rear.]