I just restored a folder that showed up in the Qrecall info window as 1.85gb in my archive and it turned into a 9gb folder on my hard drive. I guess that means that the size in the info window is the size of total data in the archive and the original data contained enough redundancy to cause it to balloon up like that. Is that right? (The original folder contained a bunch of DVD Studio Pro templates, etc., so I guess it could have been highly redundant.

The help file says that "Selecting multiple items shows the total size of all of the selected items . . ." It might be worth saying that that's the total size in the archive, and it might take a lot more space than that to restore the original files. Without knowing that, it was quite a surprise.

Ralph

Ralph Strauch wrote:I just restored a folder that showed up in the Qrecall info window as 1.85gb in my archive and it turned into a 9gb folder on my hard drive. I guess that means that the size in the info window is the size of total data in the archive and the original data contained enough redundancy to cause it to balloon up like that. Is that right?

No, it's actually supposed to be the aggregate size of the original items. There are two potentially confounding factors:

The size of items in QRecall is their size in bytes, not their size on disk. If you have lots and lots of very tiny files, they may take up considerably more space. This is the discrepency between the "size on disk" and the actual number of bytes that you see in the Get Info window.

There have been long succession of bugs in QRecall that miscalculate the aggregate size of a folder. I thought I'd gotten them all, but I wouldn't at all be surprised if there were others lurking. I may bother you again when I get around to tackling this issue again.

James, I have a similar question. Would you please clarify this for me as I'm not 100% sure what "the aggregate size of the original items" means.

In the QRecall browser, the layer pane has Layer, Date, Size, Items. Does the Size column mean:

A/ The size of the items at that point in time (ie. the disk space it would take to restore all items), or

B/ The size that this layer is *actually* taking up in the archive. This would be less than A because of QRecall's ability to only backup changed parts of a file.

I ask because my layer sizes are always around 60GB. So I'm wondering if QRecall is just backing up my entire VMWare vmdk file each time, meaning it would not be detecting unchanged parts of the file.

Crickey, I'm finding it hard to phrase this question concisely. Did that make any sense at all?

Richard,

I know it's hard to phrase the question, because these values are difficult to describe—but here goes:

There are three significant size numbers in QRecall. (1) The Size column in the layers pane is the total logical size of every item captured in that layer. This is, conceptually, the total amount of data contained in that layer.

(2) The size value that you see for individual items and folders in the item browser pane is the logical size of the file item, or the aggregate size of all items contained in the folder. These are, approximately, the same values you should see in the finder if you did a Get Info.

So if you capture a single 60GB file every day, both the size of the layer and the size of the item in the browser will say 60GB. Neither of these sizes reflect the amount of data that's shared with other items or layers. That's a really labor intensive value to determine, and an even more difficult value to explain, so I've never added this calculation to QRecall.

(3) To see amount of data that was duplicate, look in the log. At the end of each capture, the log records the logical size of the items that were captured—this becomes the size you see in the layers pane. If you expand that log line (you might need to slide you details control over to the right), you'll see a breakdown like the one shown in the attachment. This will tell you how much of that 60GB is new data and how much was duplicate.

I hope that helps.

That does help. Great info. Thanks James.