Restore files from tar using rsync

Question

I'm writing the software upgrade functionality for a piece of embedded equipment. Currently the root file system is upgraded by taking a new rootfs.tar.gz file and unpacking it to the root file system (overwriting existing files and adding new ones). But this doesn't delete files that aren't in the new package.

So now I'm going to have to rm -rf all of the existing files, then unpack the new rootfs tar file. This seems like a lot of work, and takes a lot of time, and maybe the only thing that changed was one config file.

Instead, I'd like to be able to rsync the contents of a .tar.gz file to a directory. Is this doable without going through some sort of intermediary (meaning, without unpacking the tar to a temp directory then doing the rsync)?

Answer 1

Directly, there's not any way to do what you want. As mentioned in the comments, archivemount may be an option, though it has its own limitations (one of which being a dependency on a particular config option being enabled when you built the kernel).

However, there are two alternative options that come to mind:

1. Use SquashFS images instead of gzipped tar files. These can be mounted directly by the kernel, and in many cases will actually be smaller than an equivalent compressed tar file. You can then just use rsync from the mounted SquashFS image. If you're using Buildroot for actually building the root filesystem for this, there's an option to just directly generate such an image.

2. Instead of just having one root partition, use two. When you do an initial install, write all the data onto both partitions, and set up the bootloader to only boot from the one of them. When you upgrade the system, nuke the other partition, extract your root archive there, update the bootloader to boot from that, and then reboot. While this will take a bit longer to run updates than what you are proposing, it has a couple of pretty big advantages:

   • It lets you roll-back an upgrade that broke some functionality almost instantly. Instead of having to re-install the old firmware, you just update the bootloader to boot off of the other root partition and reboot.
   • It makes it very difficult to brick the system. Because you only update the bootloader after the update is otherwise finished, you can guarantee that you won't boot into a partial root filesystem because of power-loss in the middle of an update.
   • It makes it possible to recover from at-rest data corruption in the storage hardware without needing RAID (though if this needs to be a reliable device, you should seriously consider RAID anyway). If you know your current version is 'bad', just roll-back temporarily to the previous one, and then re-install the new version.
   • It reduces downtime. For your strategy, you have to do almost everything with the device functionally off-line (otherwise you run the risk of things failing mysteriously during the update). With this method, you can reduce the downtime required for an update to however long it takes to reboot the device.