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
Copy "rear recover" log file and related data into recovered system #706
Comments
I will implement this one together with #21 |
and provide a compatibility link with where the log file was before see rear#706
Why not copy it to |
In any case, I would make sure that only root can read those files. |
I already implemented that only root can access files But I wonder why everybody can read the other files In other words: |
This particular issue is fixed with #709 |
At the end of "rear recover"
the log file /var/log/rear/
and other recovery related data
like /var/lib/rear/layout/disklayout.conf
and its matching /var/lib/rear/layout/diskrestore.sh
exist only in the rear recovery system.
When the rear recovery system is shut down
the "rear recover" related data is lost.
I like to implement that "rear recover" by default copies
the recovery related log and data into the recovered system
so that this data is later available for example for a detailled
analsysis of the recovery.
To keep the recovery related log and data strictly separated from
the other rear logs and data I like to use a separated directory
var/log/rear/recover for this.
In short:
I like to implemet that at the end of "rear recover"
basically the following is done:
I did a "rear --debugscripts xv recover" and the above
commands manually and /mnt/local/var/log/rear/recover
needs 1.1 MB disk space and with plain "rear recover"
/mnt/local/var/log/rear/recover needs needs 80 kB for me.
I do not think this "wastes disk space" and therefore
I think it can (and should) be done by default.
If there is so little free disk space that about 2 MB
for 'rear recover' with 'set -xv' and about 100 kB
for plain 'rear recover' makes a noticeable difference,
then that only points out the real problem
("too little free disk space").
The text was updated successfully, but these errors were encountered: