#2887 Issue closed: RFC: Investigate read-only mounting during "rear recover"¶
Labels: enhancement, discuss / RFC, no-issue-activity
jsmeix opened issue at 2022-11-03 10:26:¶
This issue is triggered by
https://github.com/rear/rear/issues/2886
therein in particular my comments (excerpts):
the USB disk content has to be sacrosanct during "rear recover"
...
during "rear recover" nothing of what there is
on the USB disk should ever be changed by ReaR.
cf. https://github.com/rear/rear/issues/1271
During "rear recover" all what matches ReaR sources
like /dev/disk/by-label/REAR-000 or BACKUP_URL=usb://...
must be sacrosanct
So I would like to investigate if it is feasible
and possible to implement with reasonable effort
to mount things read-only during "rear recover"
when things are only needed to be read
e.g. to restore a backup.tar.gz.
I think during "rear recover" some things may need to be
written (e.g. a some log file or something like that)
which could make it rather complicated to mount things
read-only.
See also
WRITE_PROTECTED_IDS and WRITE_PROTECTED_FS_LABEL_PATTERNS
and the related issue
https://github.com/rear/rear/issues/1271
with its pull requests
https://github.com/rear/rear/pull/2626
and
https://github.com/rear/rear/pull/2703
pcahyna commented at 2022-11-03 10:44:¶
The log gets written into the recovered system, not on the medium, AFAIK. (Writing to the medium would be USB-specific.)
pcahyna commented at 2022-11-03 10:45:¶
Also, one may even improve this by setting the device read-only at the
block device level, i.e. by blockdev --setro. This should prevent the
layout code from accidentally reformatting it.
jsmeix commented at 2022-11-03 10:52:¶
I think some log might be written to a mounted NFS share
(this issue is not only about USB but meant in general)
but that is a totally offhanded (untested) guess.
github-actions commented at 2023-01-03 02:25:¶
Stale issue message
schlomo commented at 2023-02-21 21:54:¶
I'm also in favour of mounting all external media/file shares read-only. That is a good example for defensive programming and it can save some users from accidentially erasing their backups
DEvil0000 commented at 2023-02-22 16:05:¶
not sure if all backup tools would be happy with a ro filesystem. The
for the system partition/image ro may make sense but for data/backup
partition/files this hardly depends on the mechanism/tooling used. Also
I would personally like to have a log file on the recovery media as
well. Sometimes it is a good thing being able to install packages on a
recovery system later - for example because the HW like RAID controller
or network card changed.
If it would be a ro filesystem we may want some kind of persisted or
temporary overlay rw partition as well.
I do not see a big plus in a ro recovery filesystem and you can get
this already by kernel parameters or fstab entries without the need to
change any line in rear, just config.
Note: I hate being the conservative voice -.-
schlomo commented at 2023-02-22 16:09:¶
@DEvil0000 I think the question was not about the rootfs of the rescue
system (which is in-memory in any case and ephemeral) but about external
media, e.g. NFS shares or USB drives, that contain backup data and that
we currently mount read-write even though we only need to read from
them.
"sacrosanct" meaning that we should mount those read-only to prevent potential coding or configuration errors from accidentally erasing the backups.
DEvil0000 commented at 2023-02-22 16:29:¶
"sacrosanct" meaning that we should mount those read-only to prevent potential coding or configuration errors from accidentally erasing the backups.
I know that this is your reasoning - which is very valid. I however do
not know all the backup backends possible with rear but I can think of
one organizing the data in some kind of database and needing some sort
of rw for example to mark which files got restored and when.
This may be a hypothetical and not so much a real case but we should at
least check for all backends if they are fine with ro.
Also as said one can configure rear to mount things ro even with the
current version so is there a real need for such a change?
github-actions commented at 2023-04-24 02:22:¶
Stale issue message
[Export of Github issue for rear/rear.]