There is no way to do that for the moment. Actually, the volume UUID is used in each node of the chunk tree. You'll have to change them in there also assuming that the headers of the chunks/device are not hashed. BTRFS was really not design to allow this kind of backup.

This is really sad, but the easiest way to handle that is to use another computer.

If I may, I'd like to suggest you to stop backuping your data this way.

1. If your partitions are important as a whole, backup with dd/clonezilla. When you need to restore your backups, restore the whole partition at once. Don't do this kind of hybrid backups: you specifically saved your partitions at the bloc level. So you have to restore it at the bloc level. Otherwise, you are using a spoon to cut the meat. As you certainly noticed, this solution is usually not used because it offers no versatility.

2. If your data are important, backup with rsync or a similar tool on another disk : your data will always be accessible, you backup exactly what you want, you are backuping at the file level, etc.

Note that BTRFS has some (now limited) backuping features. BTRFS is moving fast, I guess more backuping features will come out in the future.

Oh, you've been warned already ;) Automated Clonezilla backup and GPG encryption

BTW, encryption is easier to apply on files using either LUKS for partition-based encryption or EnFS or EncryptFS for file-based encryption.

All three data journaling modes should leave the filesystem itself fully intact after a power failure. So it should always mount without errors. The difference is only in the data in your files; data=writeback mode may leave stale data (i.e., what was stored in the disk sectors before the writes your app did). data=ordered and data=journaled should not do this.

Most likely what you're seeing is that I/O barriers aren't working on your setup. First, make sure you're not mounting with barrier=0/nobarrier. That boosts performance, but will cause corruption on power failure.

If I/O barriers are on, it's also possible you're passing through a storage layer that doesn't support them. On older releases, LVM didn't and various mdraid levels didn't. (This was fixed in Linux 2.6.33; so only if you're running Lucid still.)

Finally, it's possible your disks are telling lies. Disks have write caches. Especially with NCQ, they're supposed to only tell the OS they've written data when they've actually done so, but they've been known to tell the OS its written when its only in the disk's write cache. Increases performance. At least as long as the power stays on. You can try disabling the write cache on the disks, though you'll take a performance hit for this.

Note also that flash-memory disks have a lot of work to do under the hood, and many of them don't handle power failure well. (For example, wear leveling sometimes requires that a full flash block of data be moved. If the power fails in the middle, bad things happen on some flash disks.)

Finally... have you considered an UPS?