I have tried to image the internal NVMe drive using Rescuezilla, but I have failed. I have two external USB 2T drives connected. The backup failed to the first external drive twice. I cannot get most of the utilities to launch in Rescuezilla so I was unable to save the stack trace. The final line says ErrNo 5 - I/O error. Each time the following files were copied to the USB drive before the error happened:
blkdev.list
blkid.list
clonezilla-img
info-dmi.txt
info-image-id.txt
info-ishw.txt
info-ispci.txt
info-smart.txt
After two tries with USB drive 1, I switched to USB 2T drive 2, but exactly the same thing happened. The above files were copied, then an ErrNo 5 occurred. Both drives had 2 terabytes available. I tried and failed to launch all of the included apps except for filemanager, imageviewer and devicelist which did launch. I got rescuezilla from the rescuezilla website. On the chance that the error was on the internal NVMe storage device, I examined the SMART data using the nvme utility. No errors were reported. Can you suggest something more that I can try in order to get this drive imaging to work?
I was not using a key or memory stick. I was using 2 different 2 T hard drives in a dual-bay USB dock. I am going to download the iso again and re-create the rescuezilla boot key. Thanks to everyone for thinking on this challenge.
download rescuezilla
Download Zip
https://7crusin-msiso.blogspot.com/?hmrq=2x27hu
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.
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
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.
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.
35fe9a5643