Rescuezilla 2.4.1 Download
Divina Hujer
I tried the new browse a backup image. I went through the process and it seemed to work and then gave the option to open file option for that image. It just seems to show the rescuezilla in use. Am I missing something?
The image I was using was 17.1GB and it seemed to complete okay. As I recall it reported a time of around 25mins. There was then an option to unmount or open file menu. When I opened the file menu it seemed to show the content of the rescuezilla running rather than the image I wanted to browse. I was just wondering if there was some "option" or "method" to switch to the decompressed image for browsing. Perhaps I'm missing something??
So it sounds like your 17.1GB image successfully mounted after waiting a very long time. It takes a long time because Rescuezilla had to decompress the entire 17.1GB image to be able to mount most images. Then you clicked 'Open in file manager' and the file manager was opened to the folder "/mnt/rescuezilla.image.explorer". It sounds like that folder then appeared to be empty. An initially blank folder is to be expected because internally Rescuezilla v2.2 needs to decompress almost the entire 17.1GB image again to access files within it. So if you wait a long time the files will eventually appear. But then changing folders or access a file within the image will take a very long time, as the entire 17.1GB image gets decompressed for a third time etc. As mentioned this dumb behavior is a limitation of the compression settings, and I am investigating the smart way of improving things so it's fast even for compressed images.
I am having similar issues. Here is what I found.
Running the usb (created with balena-etcher) on a system with empty ssd, rescuezilla starts and works as expected. Using it on a system to create a back-up copy, the system do not see the data and hence boot from the internal SSD. I tried to plug usb on usb3 and usb2 but nothing changes.
I tried to reflash the usb (again with balena-etcher) but i get similar results.
Now I am stuck and unable to backup our system :)
We only use ubuntu 20.04 if it makes any difference.
I even tried to force booting from usb but it's like the usb is empty.
Trying same usb on an wiped out machine appears to work (it boots correctly)
Very strange as for the first day the usb worked correctly (from memory I had it in the usb3 port)
Also, strange that the system reports Low Battery when the machine is not a portable?
Anyway, hope i find a solution as it's much faster solution than clonezilla
For reference, the drive I'm trying to backup is 1TB (size shows 931.51GB) and contains 4 partitions. However only about half the space is taken by these partitions, and the rest remains unallocated. In the log ouput there are three drives: sda is PC I want to backup, sdb is the live rescuezilla usb and sdc is where I want to store the backup.
If you are able to access the folder named 'backup', please upload the rescuezilla.log file from your first attempt, it may shed some light to why the 'partclone' utility is failing. By the way, I am also very interested in seeing the files ending with "partX_partclone.log" because they may contain some information not found in the main Rescuezilla log file.
I did as you suggested and opened the external drive from Rescuezilla and the files are all there, it seems is only the Windows machine that cannot read them. However, most of the files show in the description as "inode/x-corrupted type" (as opposed to "plain text document" for example) and cannot open any of them. From the terminal is clear that something is wrong with them. I'll attach a screenshot of this, and the "rescuezilla.log" that you requested.
For Rescuezilla task #115 users had issues booting the desktop with recent NVidia graphics cards (but GRUB worked), so I created a test build of Rescuezilla v2.0 on Ubuntu 20.10 (Groovy), rather than Ubuntu 20.04 (Focal), which worked for those users. Because there has been minor changes to GRUB it might be worth trying: rescuezilla.amd64.groovy-test-1.2020-10-29.iso. Please don't use that version beyond testing the boot: upgrading the operating system often makes many internal changes, and I still need to do further testing before Rescuezilla v2.1 is released with an optional Groovy-based build (to be released hopefully within about a week).
By the way, you didn't attach the Rescuezilla log file (eg. "rescuezilla.log.202007XYZ.txt"), so I don't know the complete partition table and filesystem information of your disk, or have direct knowledge of how Rescuezilla is operating internally. Regardless, there are (at least) 3 partitions which appear to be correctly presenting themselves to Rescuezilla as /dev/sda1, /dev/sda2 and /dev/sda3. This kind of configuration commonly known as "hardware RAID" is transparent to the operating system, so Rescuezilla handles it like any other disk. This is good since as mentioned above Rescuezilla v1.0.6.1 has limited support for other kinds of RAID configuration.
In the absence of the full rescuezilla log file, as far as I can tell, Rescuezilla itself is operating completely correctly. When it reaches the third partition it's the partclone utility used internally that starts processing bad sectors and cannot continue. As you may be aware, a bad sector indicates physical damage to a hard drive. As your colleague mentioned in the email thread you forwarded me:
In the absence of the full rescuezilla log file, as best I can tell the error is in your drive array. I don't know what RAID level your drive is operating at, or other details of your environment so I can't yet provide specific advice about how best to fix bad sectors. However, Rescuezilla also provides the SmartMonTools, so I recommend you start with a full non-destructive read-only scan of your drive for bad sectors, before potentially having smartctl reallocate them. This looks like a good tutorial:
It exists for the 32-bit i386 and x86_64 architectures. The latest version is based on Ubuntu 20.10 "Groovy" which is now the main and only version on the download page and this one only seems to be available for 64-bit. At the end of last year the project also offered a version based on Ubuntu LTS "Focal Fossa". The image rescuezilla-2.1.3-64bit.groovy.iso is 885 MB. The project inherits its use of systemd from Ubuntu.
I had a similar problem. I was using rescuezilla, however, to do the cloning. I cloned the (SATA SSD) disk to the new larger (NVME) one, and then expanded using gparted. Every time I tried to boot the disk I would get BSOD errors. I tried recovering BCD and rebuilding the EFI partition etc. as noted above. In the end, out of desperation, I tried booting the cloned disk in windows BEFORE expanding it, and it worked! I don't really know why, but as shown in the answer above, windows might keep some sort of record of the size of the disk in the registry, so either you can make the registry edit as above, or boot the cloned OS from the new disk without changing it. After first boot, I was able to resize the disk.
df19127ead