#2794 PR closed
: Clean up USB backups before creating a new one on the USB drive¶
Labels: won't fix / can't fix / obsolete
ivarmu opened issue at 2022-04-21 15:26:¶
Relax-and-Recover (ReaR) Pull Request Template¶
Please fill in the following items before submitting a new pull request:
Pull Request Details:¶
-
Type: Bug Fix
-
Impact: High
-
Reference to related issue (URL): No issue created yet
-
How was this pull request tested?: VM in a home lab
-
Brief description of the changes in this pull request: If you are working with an adjusted free space into your USB drive, creating any content prior to free space may fail, making the process to abort. This PR is changing the order of the cleanup, so it'll the first step to be executed.
jsmeix commented at 2022-04-22 07:50:¶
Without checking the details here
I think this might cause a severe behavioural change
because this pull request changes
"first create new stuff, then remove old stuff"
to
"first remove old stuff, then create new stuff".
So it may happen that old stuff was already removed
but then it fails to create new stuff so nothing is left.
I worry that with the change here one may have no backup left.
In general I am against functionality in ReaR that deals with backups
(like USB_RETAIN_BACKUP_NR or NETFS_KEEP_OLD_BACKUP_COPY)
because in general any user data is sacrosanct and
in particular the user's backups are even more sacrosanct
so ReaR should only call a tool to make or restore a backup
but ReaR should not deal with backups.
Personally I would drop all functionality in ReaR that deals with
backups
but I cannot do this because this would be backward incompatible
so I leave such functionality as is and I try hard to not touch it.
See also the section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
jsmeix commented at 2022-04-22 07:56:¶
Without checking the details here
I think the current behaviour is no "bug" but intentional
(but I am not at all an expert in this specific area of ReaR)
while the impact of this change could be really a "high" risk.
ivarmu commented at 2022-04-22 09:05:¶
@jsmeix I agree with you, I didn't thought about loosing all the backups in the USB drive, what can be undesirable at all... so... I'm retiring that PR.
jsmeix commented at 2022-04-22 09:50:¶
@ivarmu
thank you for your prompt reply.
By the way:
I blindly guess (without checking the details here)
that the current code does not sufficiently test
whether or not it is actually safe to remove old stuff,
cf. the section "Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style
At least on first glance I don't see appropriate checks
e.g. a check that tests that there actually is new stuff.
On first glance it seems it works just because it keeps
by default the two (by default USB_RETAIN_BACKUP_NR=2)
topmost directories of the
ls -dt $BUILD_DIR/outputfs/rear/$HOSTNAME/*
output regardless whether or not there is new stuff
so when there is no new stuff it keeps the old stuff as is.
In general see the section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
therein in particular those excerpts
ReaR only calls an external tool that does the backup of the files
during "rear mkbackup" ... (by default that tool is 'tar').
...
It is your task to ensure your backup is consistent ...
...
It is your task to ensure your backups are kept save
at a sufficiently secure place ...
...
There is basically nothing in ReaR that deals in any further way
with what to do with the backup
...
After a "rear mkbackup" run the user has to do on his own
whatever is appropriate in his particular environment
how to further deal with the backup
Bottom line:
Don't blindly rely on ReaR to do "the right thing" with your backups.
Better safe (your backups to a really safe place) than sorry.
In particular the place where ReaR writes to
(e.g. a NFS share or a USB disk or anything else)
is not a really safe place to keep old backups.
[Export of Github issue for rear/rear.]