rescuezilla / rescuezilla Goto Github PK

There are many aspects to the application's usability that can be improved in future versions of Rescuezilla:

• Redo Backup and Recovery has never had a back button.
• Misclicking on the wrong partition may cause an error box (this is good) but exits the application
• Replace disk selection drop-down menu with a less compact menu (that doesn't require two clicks) (via Sourceforge user Graham)

While Clonezilla has similar usability issues, that is no excuse.

A user on the Redo Backup and Recovery forum in 2011 struggled to save recovered files onto their hard drive.

A graphical wizard for testdisk would be generally useful and reduce support overhead.

I have several computers with encrypted partitions. If you backup an encrypted partition it will have the exact same size it has on disk, empty or not, because the data is not compressible. This makes backups and restores take really long and takes up too much space on backup drives.
It would be good if RescueZilla would detect LUKS-(or other) encrypted partitions and allow decrypting them by typing in the password. Then backups could be either stored decrypted or re-encrypted via Rescuezillas mechanism, if the user wants that.
Here are some pages that describe the process of mounting, backing up and restoring encrypted partitions:

• Backing up/restoring a LUKS encrypted partition with clonezilla
• backups to an encrypted volume using clonezilla
• How to Clone an Encrypted Disk Image with Clonezilla

I am currently working with Redo Backup 1.0.4
If I want to backup a machine with a SATA controller safely, but want to restore it via an IDE controller, it is necessary that the PC (with me a VM in Vbox) has a SATA controller with a hard disk. Without this useless SATA controller with HDD, the restore process ends after one second.

Rescuezilla (and Redo Backup and Recovery before it) does not properly list the software RAID device nodes (eg, /dev/md0) created by the mdadm utility. A user in 2016 was using dmraid. This task will almost certainly implement mdadm RAID. Many other users need software RAID support. As of writing my background in Linux software RAID configurations is limited, so let me know if this is insufficient.

The constituent drives (say, /dev/sda1 and /dev/sdb1) are detected as linux_raid_ by the fsarchive probe command used internally, so can be independently backed up and restored. Though issue #43 (which captures the fact Rescuezilla is only able to backup/restore drives with valid partition tables) may be relevant for constituent disks in certain RAID configurations, so be careful.

Rescuezilla filters out the the software RAID /dev/mdN device nodes which leads it to being improperly handled by Rescuezilla. It's easy to add support if retaining existing technical debt. Recently, due to significant user demand, support for NVMe device nodes (eg, /dev/nvme0n1p3) was carefully added in Rescuezilla v1.0.5.1 (see #27). This did it in the simplest way possible, which retained the technical debt but was a significant task due to the NVMe naming pattern being so different to "sdzN" pattern, where z is the device number and N is the partition.

Now is a good time to make the application more scalable to arbitrary block device node: there is no need for Rescuezilla to explicitly filter block devices. It also makes a lot more sense to consider other issues together: #43 as mentioned, but also #44 (LVM support), as well as issue #4 (Clonezilla format support).

There have been a couple of threads from 2010/2011 calling for the ability to backup a drive onto a DVD.

This may be achieved by placing optical media burning software in Rescuezilla.

There are two approaches:

1. Relying on users to first backup to an existing hard drive before using burning software
2. Burning directly to disk without first backing up to an existing hard drive

Both approaches would require restore logic to handle a single backup separated over multiple disks.

Either approach is likely to be a lot of work to implement. Few people burn optical media in 2019, even with 50GB and 100GB Blu-Ray recordable disks.

It would be good to support this, but it's low priority and given the small target market it is infeasible without sufficent Patreon funding. Please comment/react if you would like this feature.

A user suggested in 2011 that the "please remove installation media" message after shutdown is not required and should be disabled.

According to Andy Hardwick (a developer I regularly correspond with, who uses Rescuezilla build scripts in his project named Foxclone), the parted utility has his Microsoft Reserved Partition filesystem incorrectly detected as an ext4 partition on his NVMe disk, which causes issue when his Foxclone project selects partclone.ext4 to do the backup/restore, rather than partclone.dd.

I suggested that he reports the bug to the parted developer, suggested that Rescuezilla does not use parted but rather fsarchiver. He responded:

Have done, although not hopeful, looks like the last update on parted was 2014, I'm running V3.2 (as installed with LM19.0). Also raised a bug on gparted which looks as though it has been more recently updated.

Still don't know whether it is specific to my motherboard/NVME drive and have a request out on the LM forum for anybody with win10 on an NVME drive to report the output of gparted/parted, no response yet.

And later replied with the output of fsarchiver probe showing that it also suffers from the bug

[nvme0n1p2 ] [ext4 ] [<unknown> ] [ 16.00 MB] [259] [ 2]

If he is correct and this is indeed an issue with parted/fsarchiver, then the Microsoft Reserved Partition on NVMe disks will likely fail to be backed up.

The report needs to be investigated. It may turn out to be an issue with that particular hard disk, rather than a bug in fsarchiver and parted.

After letting it deal with an "undefined video mode" on its own, it asks me to login to Ubuntu via a text screen.

I loaded the ISO onto my thumbdrive using a very recent release of Legacy YUMI from Windows 7 and am trying to boot a (BIOS based) netbook with 1GB of RAM from it.

If a terminal window has navigated to the mounted drive, Rescuezilla v1.0.5 cannot unmount it. Given that trying to backup a mounted drive drive is a very dangerous operation that may produce very bad outcomes, Rescuezilla should really raise a fatal error message asking to user to ensure all drives are unmounted before proceeding any further.

Just like Redo Backup v1.0.4, attempting to backup an unmountable drive produces a cryptic 'error exit' message for each partition. This situation can be triggered more easily with Rescuezilla v1.0.5 as it adds one-click mounting of drives using the file manager and the right-click menu ability to open a terminal.

I've translated the 4 files to Spanish for a new Rescuezilla release.

Rescuezilla_RedoBackup_ES-es.zip
I'll keep an eye on them until they're included in a new version. Thanks in advance!

The Redo Backup and Recovery discussion forum has occasionally suggested that TrueCrypt or other encryption software be integrated into the image, and that encryption HOWTO/instructions be provided, possibly with cryptsetup.

Bundling TrueCrypt (now maintained under the VeraCrypt name) is a reasonable idea. If the reason why VeraCrypt is not part of the Ubuntu repositories relating to licensing, then maybe bundling an installer would be a reasonable compromise.

Integrating easy-to-use encryption into the Rescuezilla wizard is worth considering, especially if it doesn't complicate the usage of the application.

Navigating backups to be able to restore individual files has been requested many times in the past.

Partclone supports --restore_raw_file flag to create a loop device using the sparse image, which can then be mounted and navigated.

The core functionality is present, so the task to turn it into an easy-to-use graphical utility that's logically integrated into Rescuezilla. This feature is heavily dependent on sufficient support on Patreon.

Users have regularly called for Rescuezilla to adopt a persistent partition to maintain files between boots.

This could be used to hold network configuration (static IP, wifi passwords etc) to make using Rescuezilla more efficient, particular for use in IT roles.

This is an interesting idea that is worth pursuing. Please post a reaction on this post if you would like this feature, as right now, it's very low priority.

There are security aspects to a persistent partition that need to be deeply considered. Alternative approaches include looking for another storage medium (eg, CD or second USB stick), and checking if contains a file (let's call it rescuezilla.cfg) in the root directory.

Rescuezilla v1.0.5 can backup and restore EFI partitions without issue, but cannot boot itself on machine with firmware that only supports booting from EFI drives and does not have a legacy boot option (eg, a Mac) without a workaround:

For systems that do not support legacy MBR boot, the fastest workaround is to download rEFInd and extract the ZIP archive. Use balenaEtcher to flash the image file named refind-flashdrive-0.12.0.img to second USB stick. Then boot the rEFInd USB stick, and use its menu to select the Rescuezilla USB stick.

Technical details: Rescuezilla v1.0.5 uses ISOLINUX to boot the ISO9660 filesystem (with isohybrid for USB MBR boot). Task is to investigate the best way to do this. This may involve completely switching to GRUB2 bootloader instead of ISOLINUX, which has implications on language selection. The menu system already needs to be overhauled to handle more languages elegantly.

Rescuezilla does not support backup/restore of drives which do have partition tables. In other words, Rescuezilla cannot backup/restore drives if the filesystem is directly created without a GPT or MBR (DOS) partition table being present. This situation commonly occurs in RAID configurations.

This important limitation has been captured on the Rescuezilla Limitations page which all new users should read.

The ability to backup/restore drives without a partition table is a crucial function, and will be implemented with high priority.

The ability to verify the health of a backup has been requested many in the past. The task is to implement this.

An Anonymous user in 2010 asked for incremental backups. Many other users have requested incremental/updateable backups.

This is a good idea, but will require some thought. Clonezilla does not support incremental backup. Supporting incremental file-based backup (rather than partition based backup) does not contradict Rescuezilla's roadmap. Indeed, it would be a very useful thing.

This is very low priority and will be years until this gets implemented unless sufficient Patreon funding. Please comment/react if you would like this feature.

I know this is a luxury but I think having a more modern looking front end would make the program look for attractive to users who stumble upon it.

A Sourceforge user has asked about the timeframe for Rescuezilla to upgrade to Ubuntu 20.04 (which will be released on April 23, 2020). I responded:

Yes, Rescuezilla will be upgraded to use Ubuntu 20.04 as soon as it is released.

Importantly, the version of Rescuezilla based on Ubuntu 20.04 will be 64-bit only. This is because Ubuntu 20.04 does not provide support for 32-bit x86 machines (except for applications like Steam). Given that Ubuntu 18.04 will continue to get security updates for 5 years, it is reasonable to continue to provide a 32-bit version of Rescuezilla based on Ubuntu 18.04 until the year 2023.

Having two versions based on different Ubuntu versions will increase the overhead to provide support to end-users, but its the correct thing to do.

There's little harm in staying on Ubuntu 18.04 for a little bit longer. Especially since Ubuntu 18.04 will be able to use the 20.04 kernel via LTS Enablement/HWE, which means any 18.04-based Rescuezilla build made after August 2020 will benefit from this. The benefit in upgrading is more recent versions of packages like GParted.

The exact timing of the upgrade is to-be-determined. Upgrading to 20.04 will happen after certain key Rescuezilla features have been implemented.

I was happy to see ReDo come to life again. I tried v1.05 for the first time today and had a few concerns. I burned ISO to a CD to make backup. The GUI seemed very much like v.104. The simplicity is why I prefer ReDo over Clonzilla. However, my issues were as follows:

1. The backup took too long. My 256GB SSD has less then 100GB of data. The back up took over 2.5 hours. With v1.04, this back up takes about 6 minutes. The write speed started over 3GB/sec and reduced to little over 100MBs. The size of the back up was 8.1GB, on v1.04 the same backup was 6.8GB.

2. Once the backup was complete, although my drives were mounted, I did not have permission to access my drives. With v.104 I typically move my backup directory after completion of the back up process.

I have not tested restoration yet (don’t want to wait two hours). I did save my logs if needed. Looking forward to v1.06. Please let me know if there is a better way or place to leave feedback. Thanks.

Redo Backup and Recovery has always released 32-bit builds. An AMD64 build would mean access to >4GB of RAM, and maybe other functionality (such ability to use special CPU instructions).

However, 32-bit builds run on virtually any machine. Additionally, Ubuntu is moving away from 32-bit builds.

At this stage, this issue appears far lower priority than other items on the roadmap.

A user of the Sourceforge forum posted in 2017 asking for clarification about Redo Backup and Recovery's support for LVM (Logical Volume Management).

As of writing, Rescuezilla (which has systematically unified prior Redo Backup and Recovery forks) continues very limited handling of Logical Volume Management (LVM) drives. Rescuezilla operates on drives (eg, /dev/sda and /dev/nvme0n1) and partitions (eg, /dev/sda3 and /dev/nvme0n1p3) and is fully able to backup/restore a single drive. Rudimentary testing using some pvcreate/vgcreate/lvcreate shows Rescuezilla is able to backup/restore a very simple LVM, because the fsarchiver probe command returns "LVM2_member", which is considered by Rescuezilla as an unknown/unsupported filesystem and therefore handled correctly via the byte-for-byte backup/restore fallback mechanism (in other words, partclone.dd).

However, it's likely for most practical configurations, Rescuezilla will not correctly handle LVMs. Especially until #43 (ability to backup/restore a drive without a partition table) is implemented.

Before LVM support can be implemented, further investigation is required. Part of the investigation involves understanding how Clonezilla implements this (relevant to adding Clonezilla format support, ie #4). Also understanding the degree to which LVM backups can be backed up in a filesystem aware manner. Finally, issue #43 (support for drives without partition tables) is likely relevant.

Because the large overhead in implementing this correctly and other development priorities to improve the experience for Rescuezilla's existing users, it may be a long time until this is implemented. It will inevitably be implemented though. As always, please like/react if this issue is relevant to you and consider supporting on Patreon.

When i try to restore a backup from a remote folder and try to connect to a smb folder using the IP instead of DNS name, redo says that cannot connect to the resource. This featured is working in the .4 version.

Rescuezilla has never supported what Clonezilla calls "device-device" mode: copying one hard drive directly to another (commonly called "disk cloning"). Many users have called for this function.

Instead, Rescuezilla currently only supports what Clonezilla calls "device-image" backup and restore. This means backing up a source drive to a bunch of files, and then later restoring these files back to a disk and is often called "disk imaging". This means during a backup process, Rescuezilla's destination is limited to a hard drives containing filesystem that Rescuezilla can write files to.

Supporting the device-device "disk cloning" mode is a key part of implementing #4 (making Rescuezilla a drop-in replacement to Clonezilla), but it makes a lot of sense to treat this feature as a separate issue that can be implemented before all of #4 is implemented.

Many users have suggested Rescuezilla's simplicity is why they prefer using this tool. The design of device-device operation must be done very carefully to avoid over-complicating the user interface.

This issue will not be a high priority until other issues on the backlog are completed. The overall effect of a hard drive clone can still be achieved using Rescuezilla's existing mode by using a third hard drive to temporarily store files.

The roadmap says Rescuezilla's primary goal is to be a "graphical, drop-in replacement to Clonezilla".

This is a reasonably large amount of work to develop and test (including backwards compatibility) so won't be released for some time.

Since Ubuntu 19.10, Chromium Browser is only packaged as a Snap. Unfortunately Snap-packages cannot be installed in a chroot: https://bugs.launchpad.net/snappy/+bug/1609903 (bug report from 2016)

Chroots are heavily used by Rescuezilla's build scripts to create a root filesystem. One workaround listed in that bug report is "pre-seeding", which leads the package to be installed at first boot. This is not suitable because Rescuezilla's read-only filesystem uses OverlayFS, which is not yet compatible with snapd as described the bug report, and because the live USB will likely be used on older hardware with weaker CPUs so the overhead of re-installing packages may become significant.

For yet-unreleased Rescuezilla v1.0.6 upgrade to Ubuntu 20.04 (only for the new 64-bit release), snap-based packages was avoided by simply switching to Firefox and disabling snapd. But this approach may not be suitable going forward. It's ideal for end-users to not to have to be adversely affected by this, so I wrote a comment in the bug report above.

Built iso, booted fine, chromium, xrandr, file manager all work, rescuezilla doesn't. From the logs:

Global symbol "$part" requires explicit package name (did you forget to declare "my $part"?) at /usr/local/sbin/rescuezilla line 1342.
Global symbol "$data" requires explicit package name (did you forget to declare "my $data"?) at /usr/local/sbin/rescuezilla line 1343.
Execution of /usr/local/sbin/rescuezilla aborted due to compilation errors.

Note that rescuezilla is 32bit and running it on a 64 bit machine if relevant.

Rescuezilla v1.0.5 revived the abandoned Redo Backup and Recovery project. As the release notes at the time said:

Renamed project Rescuezilla but keeping ‘Redo’ for v1.0.5

Rescuezilla v1.0.6 is nearing release, so it makes a lot of sense to remove all Redo Backup and Recovery logos from the live environment and replace it with some kind of Rescuezilla logo. The Redo logo is used at the bootloader, the plymouth graphical splash screen, the desktop background,
the frontend's banner and also the website:

I really like Redo's blue/orange color scheme. This should definitely stay. I also kind of like the existing wispy background with the bubbles. That just leaves the title/logo that needs changing

I am not a big fan of the recycling symbol logo, which definitely doesn't look good by itself. I like the idea of a simple cartoony Tux penguin, potentially dressed as superhero (since the application "rescues" your computer). Definitely want to stay away from the logo referencing the Godzilla character. The suffix -zilla is definitely part of the English language, but relations to the actual character still cause copyright issues.

Switching to a more unique logo will hopefully reduce confusion among users coming across Rescuezilla for the first time. Hopefully clear branding will increase the very low Patreon support numbers (which really needs to improve if Rescuezilla development to be sustainable).

Where is Redo Backup v1.0.5 ISO image ? Every link leads to github and there is no image here.
Why you did not put file on https://sourceforge.net/projects/rescuezilla/

It would be very helpful for debugging if the Rescuezilla frontend writes all stdout/stderr logging to the destination directory, at least in backup mode.

Currently the Rescuezilla PolKit/pkexec launcher script writes to a logfile on the current user's desktop. The live environment internally achieves this using an overlayfs-mounted tmpfs this file does not persist over reboots.

One consideration is this destination directory is not known until relatively far into the wizard. Therefore, it makes sense to use a Perl library function such as File::Tee to redirect a copy of stdout/stderr as soon as the destination becomes known. It seems to make sense to copy the contents of the existing log file first then start appending, so as much log information is captured as possible.

For a restore process, most users will not want their image source directory modified in any way so logging to the non-persistent Desktop directory seems fine, especially given that restore process is easy to repeat in to generate a new log file.

Rescuezilla v1.0.5.1 (and prior versions) assume sectors 1-63 are the “post-MBR gap”, which on MBR Linux disks contains a ~31 kilobyte GRUB2 core.img (called “stage 1.5” in GRUB Legacy), which is a small program that mounts the root filesystem to load further GRUB modules and then processes grub.cfg file.

Due to solid state drives and 4K sector sizes becoming more common, standard Linux partitioning aligns the first partition to 1MiB. This causes the post-MBR gap usually be sectors 1-2047. The GRUB2’s core.img is still usually <31KiB, but there is no guarantee: it’s possible to list a large list of modules during GRUB installation and make core.img much larger (hundreds of kilobytes and beyond). Rescuezilla v1.0.5.1 only copies the first ~31 kilobytes of the post-MBR gap which may be 1 megabyte in size, which can in theory truncate GRUB2 core.img and cause boot issues.

It's unclear how common GRUB core.img files larger than 31KiB are. Please comment if you know of an Linux installer which by default creates core.img file larger than 31 kilobytes.

One solution is to use the exact sectors offset to the first partition (using eg, sfdisk), so dd can copy the exact number of bytes required. Ideally this can be done with the minimum of sfdisk output processing and calculations. Also Rescuezilla is soon moving towards supporting Clonezilla-format, so it may not make much sense to add further complexity to the Rescuezilla-format backup/restore logic. Another apporach is to copy the 1MiB post MBR gap for all disks (even for older 63 sector MBR gap disks). This may overwrite the start of the first partition, while that may be acceptable given that Rescuezilla individual partition backup/restore is already very immature (#46), so it’s definitely would not be a great solution.

This issue was discovered while debugging #50, but it's not confirmed whether it was the root cause of that issue.

Rescuezilla hasn't modified the architecture of the script yet. I am not yet convinced of the correctness of the threading in the main script. There are things running on certain threads that probably shouldn't be. Eg there's definitely places where the GUI thread runs tasks that take around one second, causing the GUI to freeze. I also haven't convinced myself there are no race conditions in the codebase. This is clearly not good for the user experience, so the threading of the application needs to be examined and if necessary, fixed/overhauled.

As part of this task, may as well do a few other GUI related tasks. Also earlier versions of Redo Backup and Recovery defaulted to a nice silver theme called Bluebird. During the Ubuntu 18.04 upgrade (Rescuezilla v1.0.5) this theme switched to a dull grey default, I remember spending a little bit of time debugging this, but I couldn't figure out why so I just moved on. It's a good time to revisit this.

Finally, I am no expert in GUI toolkits. I believe the application is a GTK2 app. It would seem switching to GTK3 is a good idea, as it is suggested that GTK3 has better HiDPI support.

This task is best done now due to #49 (application state handling) already being a big refactor of the application.

For all versions of Redo Backup and Recovery, the ability to backup and restore individual partition has not been mature.

Since Redo Backup and Recovery was revived in November 2019 by a new maintainer under the Rescuezilla name, this limitation has been clearly listed with the statement that "Rescuezilla officially supports backing up and restoring entire disks. Individual partition backup and restore is very immature right now and is not recommended".

In the past, some users have asked detailed questions about this on the Sourceforge forum. The task to complete this was originally part of #4 (Clonezilla support), but it makes a lot more sense to improve this situation as a separate GitHub issue (this one), so it can be referenced in these forum topics.

The problem is:

• There is no page to select individual partitions during a restore process (which makes it all or nothing)
• The entire partition table is always overwritten.

However, there is a page to select partitions to backup. This makes it possible to to backup a single partition and IF the partition table hasn't been changed, there is an extremely rudimentary ability to surgically restore individual partitions. However, if the partition table HAD changed (eg, restoring to a different disk), the existing partition table will differ and it being overwritten is very dangerous.

Since the original version of Redo Backup and Recovery in 2010, this issue may have caused some users big issues. Since the inception of Rescuezilla, the whole disk backup/restore limitation has always been made as clear as possible.

The ability to select individual partitions to restore and not overwrite the partition table is very important to implement as soon as possible, because realistically not everyone will read the limitations page or the FAQ.

The Perl script has had notoriously poor handling of exit codes in all publicly available Redo Backup and Recovery releases. An egregious example is the backup/restore operations, where data is piped between applications such as partclone, gzip. An error in anyone of these stages is catastrophic, and breaks the application in ways that the user is not expecting, with the backup/restore operation potentially silently failing. Another example is #16.

Fixing this will likely mean big changes to the Perl script. The use of pipes may need to be replaced with UNIX named pipes (FIFOs). Alternatively, Perl appears to have IPC libraries available to help pipe data between applications and check exit codes in a robust and compact way.

This change effects the core of the application, and may force refactoring of some behavior to keep things tidy, and to ensure correctness of GUI threading. The scale of this change is why the v1.0.5 release did not attempt to solve this issue.

Successful implementation will make the application far more robust to error conditions

Rescuezilla v1.0.5 and v1.0.5.1 incorrectly compares a memory address to the length of the drive, causing the backup process to not proceed (without even a dialogue box -- #29).

Background: during the development of Rescuezilla v1.0.5, all known source code of Redo Backup and Recovery were found and unified into a git repository. I applied several changes from another developer's Redo Backup v1.0.3 patchset into the Rescuezilla git repository (specifically commit 292e1d6), but couldn’t run the application due an aspect of Perl’s values() function having been deprecated and removed in newer versions of Perl. To resolve this I created commit: c00448e to try and workaround that deprecated Perl function, then continued on. It was this second commit that introduced this bug.

In testing using Resucezilla v1.0.5.1, the value of the memory address was typically something like 0x285a234 (of course every time an application is launched, the exact memory addresses may change). This variable gets interpreted by Rescuezilla v1.0.5/v1.0.5.1 as ~42.3 megabytes and is compared against the length of the disk. If the memory address is larger than the disk size, this triggers a “stuck at 0%” issue with the status bar saying something like “Preparing to create backup of Drive 1, Part 1...” (which happens when an unexpected situation occurs early in the backup/restore process, #29 will improve the handling of this).

Please note: given the memory address varies between launches, it’s possible that larger drives could trigger this issue, but this has not yet been observed.

The incorrect comparison operation became clear during early testing of a 64-bit build (#3), as the much larger 64-bit memory addresses (eg, 0x55a0bae63808) meant the bug is triggered for any drive smaller than 94.1 terabytes – which is of course all drives as of writing, especially given Rescuezilla’s currently limited support of RAID.

An Anonymous user in 2011 requested Redo Backup and Recovery work on machines that are not connect to a monitor.

Given booting Rescuezilla using PXE boot on headless systems may be a not uncommon use case, it's a reasonable that Rescuezilla should support this functionality.

Any implementation of course needs to be balanced with security considerations. The cleanest, most secure approach is to place a configuration file in a persistent partition (see #8), allowing for a VNC (or SSH etc) server to be launched with a pre-configured credentials.

If booting with a hard drive containing a swap partition, Redo Backup and Recovery v1.0.4 and Rescuezilla v1.0.5 swapon the the swap partition automatically, according to GParted.

While swap partitions are meant to be used by operating systems, for Rescuezilla it may interfere with the backup/restore operation. Also Rescuezilla contains disaster recovery and forensic tools to recover files from a dying harddrive, where accessing the hard drive like this is a bad thing.

I have not yet come across any reports of this causing issues but there is potential that issues have happened but end users didn't realize what went wrong.

A Sourceforge user in 2010 suggested network settings be saved so that several backup/restore operations can be made without needing to enter the network credentials again.

This is a very good idea, and the credentials in Rescuezilla v1.0.5 are already written to a tmp file.

The idea can also be extended to caching between reboots (see #8), however this may be a security problem.

I've done a number of backups and restores with no issues except for LinuxMX. Backup work fine but when I restore it will not boot correctly. Keep doing a boot cycle.

I found that if I boot from USB and re-install grub this corrects the problem.

Any ideas as to why grub is not getting installed from the backup?

A recurring feature request is automatic resizing of partitions depending on the size of the destination drive.

Clonezilla supports this (#4). However, this feature is being treated as a separate task.

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.

In the unlikely event the Rescuezilla app crashes, there is a log file on the desktop that needs to be uploaded manually. Not every user will ever do this.

The best approach is a popup window with the option to review and upload the log file and create a bug report. Since v1.0.5 sensitive information like passwords are not part of the log file.

This approach keeps users in control of the data while giving Rescuezilla enough information to fix any bugs.

Currently the applications in Rescuezilla are integrated tightly with the rest of the systems. Installing each utility from a deb package would be a cleaner approach and help integrate a graphical partclone frontend into other Linux distributions.

This of course requires changes to the build system, and extracting each application into its own source tree.

I was trying to back up a laptop with an NVME m.2 drive and no partition appears after selecting the source hard drive. (The drive is detected)

I see all partition on the NVME Drive when it's time to choose the destination drive

If i continue, the progression bar stay stuck a 0% with no estimated time

My controller mode is set to AHCI

The Rescuezilla v1.0.5 build system automates the manual Redo Backup and Recovery Sourceforge Wiki instructions. This is a great improvement, but both make and make clean && make take along time. In non-clean builds, the Ubuntu packages are cached, but Rescuezilla artifacts (such as the chroot) are not.

Given a lot can be developed without rebuilding the ISO image, a relatively slow build is not a deal breaker. However, the build system can and should be able to be improved a lot.

Maybe the best path forward is deconstructing the build.sh, and chroot scripts into a Makefile so a dependency tree is managed by GNU Make. It's also worth considering if alternative approaches such as Linux Live Kit manage this problem better.

The implementation of task #1 gave the Rescuezilla build scripts EFI and Secure Boot support but gave a hard dependency on Ubuntu-package environments in order for Secure Boot to work.

In other words, building the ISO image on Debian does not produce an image that verifies on EFI firmware with Secure Boot. The reason for this is Rescuezilla is Ubuntu-based so uses Canonical-signed Linux kernel images, therefore it needs a Canonical-signed GRUB EFI bootloader image which trusts Canonical signed kernels (available at https://packages.ubuntu.com/focal/grub-efi-amd64-signed), and the standard Microsoft-signed EFI bootloader shim (eg https://packages.ubuntu.com/focal/shim-signed). However, the equivalent packages available in the Debian repository (https://packages.debian.org/buster/grub-efi-amd64-signed and https://packages.debian.org/buster/shim-signed) have the GRUB bootloader which only trusts Debian signed kernel images and not Canonical signed kernel images.

It's worth noting that this annoyance will never be a problem for official binary ISO images, as the Docker environment used by Travis-CI is Ubuntu-based.

It would be very nice to be able to develop Rescuezilla on Debian-based package environments without using Docker but still have Secure Boot work.

Therefore, given the build already has a Ubuntu environment bootstrapped (the Rescuezilla root filesystem), the script could easily to leverage that to download and extract the relevant bootloader packages to create an EFI System Partition. This does add extra complexity for the build scripts, for much more simplicity for the typical build made during Rescuezilla's development.

A user of Redo Backup and Recovery requested P2V functionality back in 2011 and suggested Symantec LiveState supports this.

The ability to convert physical media to virtual hard drives is very useful -- particularly when done in a filesystem aware manner than produces a dynamically allocated image.

This is much lower priority than other enhancements but important to consider.

A user named 'coth' on the AlternativeTo discussion forums has suggested today that restoring secondary partitions using v1.0.5 does not work, but this functionality works with Redo Backup and Restore v1.0.4.

While the Limitations wiki page has always said "Rescuezilla v1.0.5 currently only officially supports backing up and restoring entire disks. Individual partition backup and restore is very immature right now and is not recommended. (to be fixed with #4).

However, I was unaware that the behavior in v1.0.5 was worse than it was in v1.0.4. If there is indeed a bug in v1.0.5 that wasn't in v1.0.4, rather than it fixed as part of the very broad 'Clonezilla drop-in compatibility' enhancement task (captured in issue #4, which will be completed at some indeterminate point in the future), this bug will be treated as a very high severity regression from existing behavior, and will be fixed as part of the next point release at high priority.

The original Redo Backup and Recovery script heavily uses global variables for application state management, including transferring information between pages in the wizard. The heavy use of global variables makes the application state difficult to reason about. The prior releases of Rescuezilla (v1.0.5, v1.0.5.1, v1.0.6 and v1.0.6.1) left this architecture unchanged when adding new features.

The heavy use of global variables will be replaced with a cleaner, more modular approach with each page of the wizard to populating fields of a struct (backup source, partitions to backup, backup destination) which gets passed on to the next step.

Removal of the brittle global variable architecture will make it much easier to implement otherwise simple usability improvements and enhancements in a much more clean way. Such as a back button (#6), the ability to select partitions to restore (#46) and other extensions to the Rescuezilla wizard.

This will be a very big refactor of the Rescuezilla application, so it makes sense to do implement other changes at the same time, or at least lay clear foundations for them. It definitely makes sense to make the application packagable (#13). It probably also makes sense to modularize the application into separate files. The GUI threading investigation (#48) is also relevant during this refactor.

This task is foundation for the clean implementation of #4 (Clonezilla file format support)