Fix v1.0.5-v1.0.6.1 GParted resize + backup + restore behavior on GPT disks

[shasheene]

In trying to understand candrapersada's several GitHub issues (#94) spread between the Rescuezilla and Redo Rescue projects, I have discovered a bug affecting restoring to a disk smaller than the original which affects GPT disks, and can only be triggered if a user happens to have first shrank the final partition (for example using GParted) before doing a backup.

The backup can be restored to a drive with equal to or larger capacity without any problems. This a very contrived bug that almost nobody will hit, and does not happen even when attempting to do an officially unsupported "surgical" individual partition restore between disks. It requires a user to manually shrink their partitions using GParted before doing a backup and restore.

Background: Rescuezilla v1.0.5/v1.0.5.1/v1.0.6 provides a rudimentary ability to restore images to a drive smaller than the original source drive. As part of the Rescuezilla v1.0.5 task to unify all forks of Redo Backup and Recovery under a single umbrella project now known as Rescuezilla, this slightly improved functionality was imported from Michal Suchanek's git repository containing a few updates to Redo Backup and Recovery v1.0.3 which was developed between 2012-2015. Simply put, rather than using the source disk capacity to determine whether the destination disk is smaller than the source, it checks whether the end of the final partition is smaller than the destination disk.

This provides Rescuezilla v1.0.6 with a rudimentary ability to restore to smaller disk, if an advanced user has shrank the final partition using GParted.

While this rudimentary restore approach has worked very well for MBR disks, but it does not work for GPT disks: the protective MBR and primary GPT are correctly backed up at the start of the disk, but the secondary GPT (at the end of the disk) cannot be correctly restored, so Rescuezilla exits with an error informing the user that the partition table did not restore correctly. Opening GParted then informs the user first of "Invalid argument during seek on read /dev/sdX" (presumably because it is trying to read some disk sector far beyond the end of the disk) and offers a dialog box with 'retry', 'cancel', 'ignore' options. After clicking ignore, another dialog box then says "The backup GPT is corrupt, but the primary appears OK, so that will be used" (presumably again, because it is looking for the secondary GPT in some disk sector far beyond the end of the disk). GParted displays the partitions on the destination disk (which for testing purposes was zeroed before the restore operation) and after the restore it continues to display no partitions.

This error only affects the destination disk of course, which during a Rescuezilla v1.0.6 restore operation is already expected to be fully overwritten (including the partition tables). Again, all data in the backup continues to be fully safe, but it can only be restored to a drive with equal to or larger capacity than the original drive with the current latest version of Rescuezilla (v1.0.6).

I have just looked into displaying an error message to help stop such attempted restoration for GPT-formatted disks but to continue to allow it for traditional MBR (DOS) formatted disks. Unfortunately I included a change from that third-party v1.0.3 git repository which overwrites the .size file with the byte offset to the final partition. At the time I chose to keep this because it would automatically provide this feature when restoring the backup using an older version. But now in Rescuezilla v1.0.6, getting the true original source drive capacity in this scenario would require a calculation involving the sfdisk output (specifically the "last-lba" field, and ideally using the optional source sector size field). This would definitely be a lot of development and testing work (that could introduce regressions), just to support an experimental feature for a codebase that isn't yet structured that well.

Fortunately, similar to Rescuezilla v1.0.6 current rudimentary ability to restore individual partitions, this feature has not been publicized very heavily (especially since it still requires the user to either actively shrink their partitions using GParted first, and this issue has a very easy workaround is restoring to a disk of equal or higher capacity.

Given Rescuezilla v1.0.7 is coming in a few months with a major upgrade and refactor, solving this bug immediately is not the most effective strategy: the much easier solution is to add a bug advisory and most importantly modify the Rescuezilla Frequently Asked Questions and Limitations pages to de-emphasize this experimental "restore to disk smaller than original" (at least for GPT disks), at least until after the Rescuezilla v1.0.7 major upgrade is completed, especially since its plans for a modular codebase will facilitate broad unit testing that will reduce the risks of such bugs in the future. This approach will make implementing a proper fix for this easier and less likely to introduce regressions.

Again, all data in the backup continues to be fully safe, and can easily be restored to a drive with equal to or larger capacity than the original drive with the current latest version of Rescuezilla (v1.0.6). This bug just affects an experimental "restore to disk smaller than original" feature in the scenario where a user first shrinks their partitions using GParted.

[shasheene]

Fixed in Rescuezilla v2.0.

[shasheene]

I see from the traffic statistics that this issue is getting too many hits. This issue captures a bug that's only relevant for Rescuezilla v1.0.5-v1.0.6.1 which has been fixed since Rescuezilla v2.0.

The bug was around a specific situation where using GParted to shrink the partitions before making a backup then restoring to a new disk didn't work. Using GParted to shrink partitions before making a backup is a workaround that works, but it will no longer be required once Rescuezilla adds automatic resizing support (scheduled for Rescuezilla v2.3 in November 2021)