Raspberry Pi microSD Backups - Feature Request
Several people in the ATI 2020 forum reported issues backing up microSD cards containing Raspberry Pi boot images. I'm using ATI 2021, and I've had some success backing up and restoring RPi cards, but it required using external programs to make it work. I wanted to share my experience here and ask Acronis to make the process easier by eliminating the need for external software.
One thing to note is that in my tests, ATI 2021 Build 39216 didn't properly display progress when backing up the source card to a tibx image file. The status area displayed "Calculating the data size... Calculating time remaining..." for almost the entire time the backup was running, only showing progress in the last 3-4 minutes. The entire backup actually took about 1 hour for a 128GB card with about 11.7GB of data. Not sure why it didn't show progress sooner, but it eventually showed the backup as successfully completed.
In a nutshell, I can backup a card to a tibx image file, and restore to another card, even a smaller one, but the partition structure doesn't match the original card, so the new card won't boot in the RPi. I can fix the partition structure of the new card using the Gnome Partition Editor (gparted) on the RPi (or any other linux machine) and get the card to boot, but it would be better if ATI 2021 would duplicate the original structure during the restore process to save me the extra step.
The partition structure of some (not sure if it's all) RPi distros has unallocated space at the beginning of the card, followed by a small FAT boot partition, then an ext4 partition that takes up the remainder of the card. I've read that the unallocated space at the beginning of the card is to ensure the boot partition starts on a specific sector, but I don't fully understand the reason.
The thing to know is that the RPi will only boot a card if the boot partition starts on the same sector as it was on the original card the backup was made from. The problem with using ATI 2021 to restore an image to a card is that the boot partition doesn't start on the same sector as the original. And that's the problem that needs to be solved using the external software called gparted.
In my RPi experience, the FAT boot partition usually starts on sector 8192, leaving 4 MiB of unallocated space at the beginning of the card. When restoring from ATI 2021, the boot partition starts on sector 2048. Also, when I examine the structure with gparted, I don't see unallocated space at the beginning of the card, but the boot sector starts on sector 2048. So there's still 2048 sectors of space before the first partition, but it just doesn't show up as unallocated space in gparted. This differs from the source card where gparted shows 4 MiB of unallocated space before the boot partition. I'm using a Samsung EVO Select 128GB card for the source, and a 32GB version for the destination.
Since ATI 2021 restores a card with a structure that doesn't match the original, I take the resulting card, plug it into an external USB card reader, plug the reader into the RPi USB port, then boot the RPi using a different card in the onboard RPi card slot. I'm using two cards total: one to boot the RPi and another that's been restored by ATI 2021, but needs to be fixed. I then use gparted (not installed on standard RPi distro, but can be easily added) to edit the structure to get the boot partition to start on the same sector as the original, and it boots just fine. My only measure of success is whether it boots and seems to operate the same as the original.
It would be really nice if ATI 2021 could store some information about the partition structure of the source card, including the start sector of the boot partition, in the tibx file, and use it to restore with the same structure later.
I suppose you could backup and restore using sector-by-sector mode, and it might produce the right structure on the destination, but I haven't tried it because I'm not interested in that solution. It requires a backup image that's as big as the card, and a destination card the same or higher capacity as the source card.
I think Aronis should add a feature to allow recreation of the original partition structure on microSD cards, and then market ATI as a solution for RPi backups. The internet of things is a growing area among developers, and backup solutions are needed to keep card images organized and allow recovery from failures. There are some other backup software apps that advertise the ability to backup RPi cards, but I passed on those in favor of ATI since I've used it for over a decade and already have confidence in it. I would like for the process to be easier, and it seems like this could be a small change that would add a much needed capability.
Joseph
I use a Raspberry Pi and I've created images using True Image of the micro sd card and restored it to the same micro sd card and different micro sd cards without any boot up issues whatsoever, which I've also restored my image of Retro Pi onto a friends micro sd card and it booted fine on his Pi.
The version of True Image I use is 2019.
Steve, I've submitted a feedback request on this. Thanks for the suggestion. I realize ATI is meant for Windows, but it's also a solution that's almost working for me for RPi, so it would be good for it to be officially supported.
Alan, I also had a few occasions where the resulting ATI restore booted without modification in gparted, but I couldn't repeat it, so I didn't report it in my original post. I haven't tried ATI 2019. I tried my old ATI 2015 to start, then found that it didn't work, so I upgraded to ATI 2021 and got the results I reported above. If you ever upgrade to ATI 2021, it would be interesting to see whether you get the same results. The images I've tried to backup are the standard raspi distro, and a couple of versions of libreelec. I tried several methods of initially creating the cards, including the Rapberry Pi Imager, and Balena Etcher, and found they all start the boot sector at 8192. And ATI 2021 seems to always start at sector 2048, except for the couple of times it came out correctly at 8192, but not repeatable.
Joseph
I was curious, so I installed True Image 2021 and created an image of my Raspberry Pi (see included screenshot) and when restoring to another blank micro sd card the Pi didn't boot up at all (just a blank screen). However restoring an image made with True Image 2019 (using True Image 2021) to that micro sd card booted without any issues.
True Image 2019 hasn't failed me whatsoever (especially regarding imaging and restoring micro sd cards from Pi`s).
That's interesting. Sounds like ATI 2019 creates images differently from ATI 2021. So maybe 2021 just needs to go back to the old way of creating images to allow for easier Pi card backups.
I had something like that in reverse. I tried backing up Pi cards with ATI 2015, and it didn't work, so I upgraded to ATI: 2021, then tried restoring the old ATI 2015 image, and again it didn't work. So then I made a new backup of the Pi card using ATI 2021, then restored using ATI 2021, and it worked after correcting the partition structure in gparted.
Also, I tried another Pi distro call XBian, and it's very different from the standard RaspiOS and Libreelec partition structures. It has a boot partition, followed by a large btrfs partition, followed by a linux swap partition. Neither gparted nor ATI 2021 know how to deal with btrfs. So after booting the Pi to the card the first time, where it automatically resizes partitions to take up the whole 128GB card, ATI 2021 creates a backup image of the full 128GB, even unused sectors, since the btrfs partition must just appear to be a block of data. I'm sure that means I couldn't restore to a smaller card. Smaller image files and the ability to restore to smaller cards are the reasons I'm using ATI over other backup methods. Even if ATI 2021 were able to backup just used sectors to the image, and restore to a smaller card, gparted doesn't support btrfs, so I wouldn't be able to change the partition structure to allow it to boot. I've given up on XBian for this reason, and for other reasons. I guess the lesson is that it would be difficult to have a Pi backup solution that works for everything, but the most common distros could probably be handled.