Save images and Rescuezilla at the same drive
The Swiss Army Knife of System Recovery
Brought to you by:
rescuezilla
Menu
▾
▴
Hi,
I want to store the Rescuezilla images and Rescuezilla at the same drive.
Because Rescuezilla is mounted as cdrom it is not possible to get access
to a second partition of the drive.
Is there any possibility to solve this?
Regards,
Julia
voici ma solution
Hi Julia,
Rescuezilla v2.0 tries to prevent users from saving or restoring images onto the same drive that Rescuezilla was booted from. This should also apply when the Show hidden devices (for advanced users) checkbox is ticked.
The easiest workaround is to boot Rescuezilla from a USB thumbdrive and then use a external USB harddrive to hold your backup images. For the best possible experience, I recommend using fast USB thumbdrives, but even an older thumbdrive with a mere a 1GB in capacity will work fine.
It does sound like the current approach is preventing users from using Rescuezilla the way they want. I was previously intending on revisiting this situation for implementing a persistent partition between boots (task #8) -- which is a very low priority task. Can you please provide further information about exactly how you prepared your Rescuezilla boot media?
Last edit: Rescuezilla 2020-10-27
Hi,
I used rufus (https://rufus.ie/) to generate the USB drive.
And there I selected the "Write in DD Image mode". So it is possible after the generation to create a second partition on the USB drive. But when rescuezilla is booted I can't access the partition on the drive.
Wow, thanks for bringing this Rufus feature to my attention! I hadn't realized it had added the ability to create persistent partitions.
I have reproduced your report: the issue is the persistent partition created by Rufus (an ext3 filesystem) is being automatically mounted by Rescuezilla as the /var/log folder) and will resolve it as task #130, hopefully as part of Rescuezilla v2.1 which should be released in the next few weeks.
I have also added a comment on task #8 (Persistent partition between boots) to capture some notes/details of the Rufus persistence feature you described.
For Windows/macOS user reading this, I should probably highlight the method described above is creating an ext3 filesystem, which is generally not recommended for non-Linux users because it won't be easily accessible on Windows/macOS systems without using a third-party filesystem implementation (which is risky).
Okay, I will wait for Rescuilla Version v2.1.
But I don't understand exactly what you mean with the ext3 filesystem.
Do you mean the Rescuezilla partition is ext3 formated and this partition cannot be accessed by Windows/macOS user? Okay I think this is correct.
But the second Partition to save the images could be formated as ntfs or fat32 partition.
Then I can copy the image to a windows PC.
You are correct, if you format the second partition as NTFS or FAT32 you will be able to interoperate with Windows. I want all interested users to be able to make persistent Rescuezilla bootable media, so it's important the approach is as simple as possible. Due to the /var/log folder mounting issue you won't be able to format this partition using the GParted Partition Editor from within Rescuezilla v2.0 itself, because the partition will be already mounted.
As mentioned once the /var/log mounting issue is resolved, Rescuezilla v2.1 also needs to allow partitions on the Rescuezilla boot media to be used as a backup destination or restore source -- a feature which users have been prevented from doing up until now.
Hi Julia,
Just writing to let you know that Rescuezilla v2.1 does not make any changes to the persistent USB feature. However it does make a large amount of other important fixes so it's still important to upgrade (to a standard non-persistent USB drive that will be fully erased)
I still intend on getting full persistent working, but it hasn't been a high priority and I have limited time. I have been spending more time that I intended on Rescuezilla recently so to get back to my 4-6 month release schedule, Rescuezilla v2.2 will be released after April 2021.
Hopefully I will be able to get this feature complete for that release. There's a number of internal modifications that need to be made for the Rescuezilla frontend to be able to read and write to partitions on the device its running on (operations which are currently blocked/hidden for user safety reasons). This makes the change more involved.
I will post any updates on GitHub task #8 rather than on this forum thread.
Last edit: Rescuezilla 2020-12-18
Hi, I think I have the same question. I have an 8TB USB drive. I would like to install rescuezilla on a bootable partition and then use the rest of the drive to hold backups. Yes, it is easy to just boot rescuezilla from a thumb drive, but it would be a little more convienient to just need one device. My idea would be to install rescuezilla, boot from it, and then shrink the partition to be just big enough and then add another or multiple partitions for backup targets.
This is not a high priority item. but I think it is a nice to have. In any caase, thanks for all your work it is much appreciated.
Hi Anonymous,
Thanks for the kind words. Yes, it does sound like you are asking for the same feature. The design discussion is progressing in GitHub task #8. Given the return to a 4-6 month release cycle, I am hoping to implement this feature for Rescuezilla v2.3 scheduled for approximately November 2021 (the release after Rescuezilla v2.2 scheduled for May 2021).
Hopefully you (and anybody reading) can give Rescuezilla a 'like' on AlternativeTo so that more people can discover Rescuezilla!
UP+
same here. it would be very convenient to have rescuezilla booting from the same usb-drive whre the backup images are located (just have 1 device for all your backup/restore needs).
It's a fair point, and I know so many users want the feature. As mentioned above, I have detailed design ideas in GitHub task #8.
I definitely hope to implement a persistent partition eventually, but it is still a pretty niche feature.
I am trying to prioritize my finite time to maximize user-impact, and the user-impact I will have from creating an easy-to-use graphical frontend to TestDisk undelete (task #12) happens to be far larger than anything else I can spend my time on.
The feature will definitely be part of Rescuezilla eventually but it will take much longer than initially predicted due to my focus on higher impact tasks.
This is possible. Format your USB device with two partitions. The first partition is only large enough for Rescuezilla to be extracted to and formatted with FAT32. I extract the contents of the Rescuezilla ISO onto the first partition and the second partition is also formatted with FAT32 or EXT4 and this is where I use for storage of image files and other data.
ok. i got it working
what i did:
1. use rufus to create the bootable usb-drive, make sure to select "Write in DD Image mode".
2. open diskmanager in windows and create a new partition and format it as ntfs
3. boot your usb-drive (or stick) and select 'mount USB into RAM' in the grub menu. this is important because if you don't, you will get an error 'device or resource is busy' when selecting the ntfs partition as target.
OK, you've both convinced me to provide an official persistent partition approach for Rescuezilla v2.3
Yes, as described in GitHub task #8 and this forum topic, Rufus (the popular graphical tool to create bootable USB sticks on Windows) is able to create a persistent partition. There is some debate on how "hacky" and reliable Rufus is in that GitHub page, but those concerns can be handled by the developer of the Rufus tool and Ubuntu itself.
But yes, using "mount USB into RAM" is a good temporary workaround for Rescuezilla v2.2 in a persistent environment. But here's what I'll do to improve things for Rescuezilla v2.3 (scheduled for release next month). I will implement task #265 (Ability to backup and restore partitions on same physical drive task). This will improve Rescuezilla for all non-live environments (fixing the "device or resource is busy" bug etc). I will also write official Rescuezilla documentation on how to create a Rescuezilla persistent environment created by Rufus.
Having well-documented and tested instructions around Rufus is the fastest and easiest approach. It will ensure all the logic around making persistent USB sticks for Ubuntu-based environments is handled by the Rufus project, rather requiring me to forever write, test and maintain Rescuezilla build scripts for such a niche feature.
Thanks again for keeping pushing for this feature to the top of the priority list! I will get it complete, well-documented, tested and released in less than a month from now.
Last edit: Rescuezilla 2021-10-22
Could you please provide a solution with documentation how to realize a recovery using an image file on the same disk but differnt partition than the parition to be restored?
Hi Team Rescuezilla,
Just spotted the following comment in the v2.3 release log on the 24/12.21 "Some bugs and important feature requests from Rescuezilla v2.2 continue to remain yet-unaddressed, including unfortunately the highly requested 'persistent partition' feature as it still requires further changes and testing." When will this highly desirable feature be available please?
Well, the Rescuezilla "team" is just me.
When I wrote the comments above late last year I still had a little bit of time before I started my new job, and I unfortunately couldn't work on task before I moved countries (which is why Rescuezilla v2.3 was released during the 2021 Christmas / New Year time frame, which was much later than I had intended).
I continue to work on Rescuezilla when I have motivation (it comes in bursts), but I'm much more time constrained than I used to be.
I will try and get this done for the upcoming Rescuezilla v2.4 release, which should be released in the next 4-6 weeks.
Please do - it's much needed. Who wants to connect up multiple devices. I have one drive with multiple paritions - restore from one parition to another should be possible.
voici ma solution
I would like to restore one partition from an image file located at another partition but from the same disk. Using Macrium Reflect this works flawlessly, but since I use BTRFS, and this is not supported by Macrium Reflect (intelligent backup), I switched to Rescuezilla. I keep getting de message: "destination device cannot be the same as source image device". Is there a solution to continue, despite this message? I'm looking forward to a solution.