Restore attempts to unmount the original partition, which can cause a silent failure #36
Comments
|
This issue is fixed by commit 91faaec. (Note: the commit message incorrectly states the issue was introduced in a recent prior commit. As noted in this issue, the bug was present in every Redo Backup and Recovery release ever made). |
shasheene
added this to To do
in Rescuezilla v1.0.5.1 Milestone Kanban Board
via automation
shasheene
added
duplicate
This was referenced Feb 18, 2020
shasheene
added a commit
to shasheene/rescuezilla-dev
that referenced
this issue
Feb 26, 2020
Writes the source partitions in the form of 'sdzC' when backing up NVMe drives, rather than writing actual source partition (in the form 'nvmeAnBpC'). This makes a backup created from an NVMe drive using the next Rescuezilla release (v1.0.5.1) able to successfully be restored to a non-NVMe drive using Rescuezilla v1.0.5. The reason for this is Rescuezilla backup and restore operations processes the source and destination partitions, and v1.0.5 did not support device nodes in the pattern nvmeAnBpC. The source partition written to the backup does not really matter: it may have some usefulness to a end user, but its use in Rescuezilla is just to extract the each partition number. Therefore to maximize compatibility and restoring backups with different versions of Rescuezilla as far as practical, the source partition may as well be written as 'sdzC', rather than the backup file containing a list of the source partitions in the form 'nvmeAnBpC'. Please note, the base device 'sdz' has no special significance other than being the 26th SATA/SCSI/SAS/USB hard drive in the system (which is unlikely to be present). Also the fact that 'sdz' is unlikely to be present in the system helps avoid the "accidental unmount of source partition" issue detailed in issue rescuezilla#36, which has been fixed for the next Rescuezilla release (v1.0.5.1) but was present in v1.0.5. Again, see issue rescuezilla#36 for full details. Fixes rescuezilla#27
shasheene
added a commit
that referenced
this issue
Feb 26, 2020
Writes the source partitions in the form of 'sdzC' when backing up NVMe drives, rather than writing actual source partition (in the form 'nvmeAnBpC'). This makes a backup created from an NVMe drive using the next Rescuezilla release (v1.0.5.1) able to successfully be restored to a non-NVMe drive using Rescuezilla v1.0.5. The reason for this is Rescuezilla backup and restore operations processes the source and destination partitions, and v1.0.5 did not support device nodes in the pattern nvmeAnBpC. The source partition written to the backup does not really matter: it may have some usefulness to a end user, but its use in Rescuezilla is just to extract the each partition number. Therefore to maximize compatibility and restoring backups with different versions of Rescuezilla as far as practical, the source partition may as well be written as 'sdzC', rather than the backup file containing a list of the source partitions in the form 'nvmeAnBpC'. Please note, the base device 'sdz' has no special significance other than being the 26th SATA/SCSI/SAS/USB hard drive in the system (which is unlikely to be present). Also the fact that 'sdz' is unlikely to be present in the system helps avoid the "accidental unmount of source partition" issue detailed in issue #36, which has been fixed for the next Rescuezilla release (v1.0.5.1) but was present in v1.0.5. Again, see issue #36 for full details. Fixes #27
|
Change released as part of Rescuezilla v1.0.5.1 (2020-03-24) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
During a restore operation, Rescuezilla v1.0.5 (and every single Redo Backup and Recovery ever released since the first public version 0.9.2 in June 2010) incorrectly tries to unmount the destination partition.
Instead of attempting to unmount the destination partition (let's say /dev/sdb1), the partition device node which is attempted to be unmounted is that of the original source (let's call it /dev/sda1). This is the device node that was present when the drive was backed up, but its meaning during the restore operation may be very different, because the hard drive environment may have changed significantly.
In the best case scenario this incorrect unmount has no functional impact: it attempts to unmount a partition that is not present, or a partition that is mounted but has nothing to do with the restore operation. However, if this partition is being used as the source drive containing the backup files, the unmount operation causes all subsequent partitions to not be restored.
This situation only can occur when the harddrive order has changed (due to removing and inserting hard drives or USB sticks) such that the harddrive that was backed up earlier is now the drive containing the files that are intended to be restored. Typically, this disastrous situation happens on the first partition: The MBR will have already been overwritten, so a partition tool such as GParted will show all partitions the correct size but with an unknown filesystem (which users will consider a corrupted file system). The restore operation will appear to be very fast and the overall restore operation will show full success (due to the exit code handling of #29 not having been implemented yet).
The fact this issue was not fixed by the original author is suprising. It has likely been hit by countless users over the decade, and was present since the first release. This issue can only happen when hard drives ordering has been modified (by removing drives and moving them around etc), so the original author must not have been testing that kind of case.
The text was updated successfully, but these errors were encountered: