some puzzles about multiple sets of the same volume in one archive

I have an archive for my main system partition which was started on 1/31 this year. I've since reinstalled my system from scratch once, and reverted my system back to an earlier state numerous times, though the name of the partition never changes. (The arrangement was described in greater detail in an earlier post at http://forums.qrecall.com/posts/list/522.page#2419.)

Throughout the time I've always backed up the system partition to the same archive. For unknown reasons QR sometimes considers the system to be "new" and recaptures everything. The "full" backup takes longer, but doesn't take more space than it should thanks to QR's excellent deduplication capability, so I don't really mind.

Today QR did it again after I 1) imaged my system partition by booting into the rescue partition, 2) restored one of my earlier system image with QR v.1.2.3 installed, in order to test if b11 would crash after installation (no, it didn't), 3) restored my system with the image produced in step 1, 4) installed QR v2 b11 and 5) ran the system capture action.

As a result, I have 4 sets of captures for the same volume in the archive (see attached screenshot below). Look closer and you'll see the newest set (set no.1) has another "incarnation" before 8/1. Odd, isn't it? Furthermore, set 1 and 2 have the same layers from the start to 8/1 (in the red circle). How is that possible?

Another oddity: I went through the same steps described above to test b10 about a week ago, and yet b10 didn't consider the system "new" and continued to backup to the old set (set 2). How come b11 did it differently?

While I don't particularly mind QR starting a new set from time to time, this practice does have its down side: when digging through the archive for some earlier versions of a file, I can't reach all versions of the same file easily.

Hence, a question: is there a way to "merge" the sets? If not, please consider it a feature request. Thanks!

[Thumb - 4.jpg]

Filename 4.jpg

Description No description given

Filesize 99 Kbytes

Downloaded 1012 time(s)

[Disk] Download

Accurately identifying volumes is a tricky business. The name of a volume is essentially useless for identifying it; there are probably 50 million hard drives all named "Macintosh HD" in the world. Plus, renaming a volume doesn't make a new volume.

Awhile back, OS X began assigning each volume a UUID (Universally Unique Identifier), where possible. This is used in aliases and bookmarks to reliably identify a volume, and is QRecall's preferred method. The UUID is used, for example, to determine what device to mount when trying to resolve a link to a file that's on an unmounted volume.

If you install a new drive, or repartition a drive, OS X will assign that volume a unique ID.

Mirroring a drive, block-level cloning of a volume, and similar techniques can, however, result in two volumes with the same UUID. This can result in confusion. OS X tries to combat this by spontaneously changing a UUID if it discovers it isn't unique. But that typically only happens if you clone a drive and then mount it alongside its original.

On filesystems/devices that can't support UUIDs, QRecall falls back to using a combination of the volume's size, the date it was created, and (as a last resort) its name.

So to answer your question, in a roundabout way, some of the things you're doing (installing new hardware, repartitioning) will result in QRecall treating the new volume as a brand new volume. Other techniques, like block-level cloning, may trick QRecall into thinking the new volume is the same one it has seen before.

If you're interested, you can see the UUID (if any) of a volume using the diskutil info command.

Ming-Li Wang wrote:While I don't particularly mind QR starting a new set from time to time, this practice does have its down side: when digging through the archive for some earlier versions of a file, I can't reach all versions of the same file easily.

Hence, a question: is there a way to "merge" the sets? If not, please consider it a feature request. Thanks!

QRecall > Help > Guide > Advanced > Combine Items.

So to answer your question, in a roundabout way, some of the things you're doing (installing new hardware, repartitioning) will result in QRecall treating the new volume as a brand new volume. Other techniques, like block-level cloning, may trick QRecall into thinking the new volume is the same one it has seen before.

I'm aware of UUIDs and except the one time I reinstalled the system from scratch, it should not have changed since I used OS X's Disk Image tool to image and restore the system. No hardware change took place recently, either, certainly not after I tested the v1-to-v2-crash issue when beta10 came out a week ago. That's why it's a puzzle to me: same procedure, different results.

QRecall > Help > Guide > Advanced > Combine Items.

Doh! I read it months ago, and apparently forgot about it. Sorry and thanks!

Wait, the "combine" command is grayed out if I choose all 4 volumes. Only 3 of them--1 or 2 with the other two--can be combined. In other words, volume 1 and 2 can't be combined. This is probably due to the fact reported in my previous post that the two volumes have "parallel" layers (circled in red in the screenshot).

Just read the "Limits of combining items" in the Help, and found a note about volumes with overlapping captures can't be combined. I guess that's it. The problem is: volume 1 and 2 shouldn't have overlapped.

Looking closely, I found the "overlap" was from 7/4 to 8/1, and 8/2 might be the day I started trying out beta 10. (Not sure, but likely.) If that is true, then does it mean both b10 and b11 thought, when making their first backup, they were continuing the volume started on 7/4 (the day I reinstalled my system from scratch), and yet b11 thought, at the same time, the volume has changed from the previous day. How is that possible?

Ming-Li Wang wrote:Looking closely, I found the "overlap" was from 7/4 to 8/1, and 8/2 might be the day I started trying out beta 10. (Not sure, but likely.) If that is true, then does it mean both b10 and b11 thought, when making their first backup, they were continuing the volume started on 7/4 (the day I reinstalled my system from scratch), and yet b11 thought, at the same time, the volume has changed from the previous day. How is that possible?

I don't know, and there's no easy way to determine what identifiers QRecall was using at the time to match the volume.

Oh, and to make matters more complicated, QRecall 1.x uses a different method for identifying volumes. Prior to 2.0, QRecall used a combination of the filesystem identifier (part of the BSD filesystem API), volume creation date, size, and name.

James Bucanek wrote:Oh, and to make matters more complicated, QRecall 1.x uses a different method for identifying volumes. Prior to 2.0, QRecall used a combination of the filesystem identifier (part of the BSD filesystem API), volume creation date, size, and name.

Ah, this might be it. Remember I dialed my system back briefly to a state when it had v1.2.3 installed in order to confirm the fix for v1-to-v2 crash? QR might have touched the archive then since it started with the system.

Never mind. At least I can reduce the number of volumes to 2.


Filename	4.jpg
Description	No description given
Filesize	99 Kbytes
Downloaded	1012 time(s)
Download