QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Steven J Gold
Forum Index » Profile for Steven J Gold » Messages posted by Steven J Gold
Author Message
James, let me chew on your reply (have to feed the cats now) but I do have a suggestion from the Human Interface Design point: To many, seeing a "Zero KB" value is misleading; what it really means here is "We don't know" but Zero may be interpreted as: 0, nothing, OMG all of it is gone!

How about using something else like "Unknown" or "?" instead when a value can't be computed?
I recently had to repair an archive damaged when a cat disconnected the drive the archive was contained on during a capture.

I repaired the drive, but it failed when I verified it, so I ran repair again, after which it verified OK.

I now have 2 different layers within the archive which show as <layer#><Date> Zero KB Repaired

(strangely to me the dates of these layers are from 2017 & early 2020 -- I would have expected them to be near the date of the interrupted capture?)

•What is the status of those 2 layers?
•Why are they displayed?
•If they now are empty, shouldn't a Merge have removed them?
•What happened to the data contained in them? (I would have expected any unrecoverable data to be at the end of the archive where it was being added to when interrupted?)
I've been running Catalina under as a Parallels VM and haven't yet requested a trial Key for that, but with the official release approaching I thought I'd ask:
Any known issues with QRecall under Catalina?
That makes sense. Thanks!
Ah thanks, that's a start.

But why do almost all the items in the layer report a size (in sizes view) of "-1 bytes" and "Size undetermined" in the info panel?
I backup my iMac several times a week.

I have the backups configured to ignore stuff in the cloud such as dropbox, OneDrive, Google Drive, the Photos system library, etc.

Most of the backups capture between one and two Gig and after de-duplication end up writing something between 300 to 700 MB to to the archive.

Today my backup captured 12.13 GB and wrote 5.26 GB to the archive after de-duplication and compression and I can't figure out why. This happens occasionally. I don't know what I did which would cause so many files to be captured as I don't recall doing anything on the iMac to do that.

So I'm really curious – – is there any way of looking at a specific layer/backup to see what files were captured, especially if there are any large ones?

Here's an abbreviated copy of the log entries from my last two backups – – the more "normal" one And the curiously large one.

Action 2019-06-18 12:06:48 ------- Capture to Backups.quanta
Action 2019-06-18 12:06:48 archive: /Volumes/Seagate/QRcall Archives ƒ/Backups.quanta
Action 2019-06-18 12:06:49 Capture Lion
Action 2019-06-18 12:06:49 Minutia Locating changes since Sunday, June 16, 2019 at 1:03 PM
Action 2019-06-18 12:10:57 Minutia Recaptured files
Action 2019-06-18 12:13:04 Excluded items
Action 2019-06-18 12:17:09 Ignored changes
Action 2019-06-18 12:20:18 Captured 2199 items, 1.46 GB (49% duplicate)
Action 2019-06-18 12:20:19 captured: 1.46 GB (1,460,142,366 bytes)
Action 2019-06-18 12:20:19 written: 377 MB (376,956,800 bytes)
Action 2019-06-18 12:20:19 duplicate: 719.9 MB (719,869,887 bytes) 49.30%
Action 2019-06-18 12:20:19 rate: 108.6 MB/min
Action 2019-06-18 12:20:19 files: 5,655
Action 2019-06-18 12:20:19 folders: 1,486
Action 2019-06-18 12:20:19 icons: 0
Action 2019-06-18 12:20:24 ------- Capture finished (13:35)

Action 2019-06-21 13:11:33 ------- Capture to Backups.quanta
Action 2019-06-21 13:11:33 archive: /Volumes/Seagate/QRcall Archives ƒ/Backups.quanta
Action 2019-06-21 13:11:34 Capture Lion
Action 2019-06-21 13:11:35 Minutia Previous layer had no bookmark; performing deep scan
Action 2019-06-21 13:55:49 Minutia Recaptured files
Action 2019-06-21 14:13:48 Excluded items
Action 2019-06-21 14:48:36 Captured 8245 items, 12.13 GB (45% duplicate)
Action 2019-06-21 14:48:36 captured: 12.13 GB (12,125,567,163 bytes)
Action 2019-06-21 14:48:36 written: 5.26 GB (5,258,723,768 bytes)
Action 2019-06-21 14:48:36 duplicate: 5.5 GB (5,502,469,402 bytes) 45.38%
Action 2019-06-21 14:48:36 rate: 125 MB/min
Action 2019-06-21 14:48:36 files: 28,306
Action 2019-06-21 14:48:36 folders: 5,375
Action 2019-06-21 14:48:36 icons: 0
Action 2019-06-21 14:48:43 ------- Capture finished (1:37:09)
I have a large archive (close to a TB) so the Compact action takes 12-20 hours to complete.

I know I can safely pause/stop a Compact action and resume it later, but what would happen if I attempted to take another backup (recapture) before the Compact is restarted & completes? What about a Merge?

I'm assuming the archive won't be damaged, but would to Compact have to start all over from the beginning?
Curious minds want to know...

I have a 5 GB disk image file I'm backing up.
Actually, it's a "Sparse Disk Image Bundle" consisting of 560+ "bands" each of which is an 8.4 MB file.

I notice when I write to/modify the mounted disk image, the Date Modified for some -- but not all -- of the individual band files change.

When backing up, does QRecall treat each of the bands as individual files even though at the higher level the OS (like Finder) treats the conglomeration as a single file?

If I write to the mounted disk image resulting in say 100 out of 560 of the band files being changed, will QRecall only recapture the changed band files as opposed to the entire bundle?
I did a "Nuke and Pave" on my computer while upgrading to High Sierra to rid myself of over 10 years of accumulated crud and junk files which I did not want carried over to a new installation.

Prior to erasing the disc, I did a backup (actually, several backups ) and my intent was to use QRecall to restore the particular apps and data I wanted from the prior system to the new one.

But I'm running into a problem: on my new clean virgin system my ID (sjg) has a different UID number (501) then on the prior system I backed up (503). Apparently QRecall restores the old files using the UID number to set ownership instead of the name so I ended up not owning the files which I previously owned!

This is not easily rectifiable from the Finder since I am not the owner of the files.

Is there a way to restore files from a backup, using the owners name to set ownership instead of the UID?
Obviously, I prefer to use QRecall but using the advice one maintains multiple backups on multiple physical media, I also maintain an occasional Time Machine backup.

Do you know if for now (until Apple fixes the bootable APFS issues) you can boot into the Recovery Partition and select the option to restore from a Time Machine backup and that will give you a bootable APFS partition?

Could you then restore from QRecall over that?
I'm taking advantage of the need to install High Sierra to do a "Nuke & Pave" -- ensuring I have a current 10.12 QRecall backup, completely wiping the partition, cleanly installing 10.13, and then restoring selected items to the new system.

Since I have a SSD in the computer, the installation process will convert the HFS+ to APFS.

Will I be able to restore stuff from the QRecall backup under HFS+ to the new APFS partition without any issues?
Will file permissions, extended attributes, and other meta-deta all be set correctly ?

With the release just around the corner, are there any known issues? Can QRecall backup and restore non-HFS+ volumes ?
Remember RAM Doubler from Connectix back in the 90's? It combined compression with virtual memory. I had a friend who worked on it back then and one of the principles which it was built on was they discovered it was always faster to compress/decompress data -- in this case memory -- than to write it out to disk, by a magnitude of order. Microsoft bought Connectix in 2003, primarily to get Virtual PC. Connectix's patents on memory compression expired, and recently Apple used stuff from them to implement Memory Compression in what, Yosemite?, because it was faster to compress memory than to swap it to disk.

I actually found that the fastest way to move a large file (40+ GB) file from a USB-2 connected disk to my laptop is to Restore it from a QRecall archive to the target disk rather than do a straight copy. I assume this is because the archive is compressed and thereby takes fewer I/O operations to "read" the file than to do a Finder copy from the external disk?

(I would never have guessed I'd use QRecall as a "faster than Finder file copier" )
Ah, so that helps explain why the first backup of the new disk wasn't as fast as an initial capture -- the need to read the earlier backups for de-duplication.

It never appeared to be stuck, just varying in speed.

Thanks for the explanation!

BTW, does the existing quanta need to be decompressed for the comparison, or does the comparison operate on the compressed data?
I guess I'm asking if the de-duplication process is slower if the archive is compressed?
I replaced a terribly slow internal HD in my laptop with a new SSD of approximately the same size, capturing the "old" volume(s) one last time before the swap.
Then I cloned the old drive to my new using Carbon Copy Cloner. Tremendous difference in SSD vs. HD performance experienced in computer snappiness.
I also renamed the new internal SSD volumes to avoid confusion with the removed hard drive (now living in an external enclosure(.

Then I went to capture the new volume with QRecall. Since the newly installed and partitioned SSD has both different internal ID and different volume name, I expected QRecall to capture it as a new volume but since its contents are almost completely identical to the prior replaced volume, I expected the Capture to find 99% of the data already in the archive (it turned out to be 98.69%) and complete very rapidly.

So I was surprised when it took over 4 hours to capture 167.7GB since it actually only needed to write 1.53GB.
Most surprising was the variance in speed it reported. Sometimes it reported "1.63GB per second", but sometimes only "7.28 *MB* per second" -- that's quite a magnitude variance(!). The average rate was 687 MB/min. I'm curious why it sometimes dipped into the single MB/sec digits.

Relevant facts are: the backup archive is 897 GB, on an external drive connected by USB-2. Shifted Quanta Detection is off, Capture Compression is set to maximum, Data Redundancy is None. 1,278,260 items were captured. Doing the math, it looked like 670 MB was saved by compression.
Forum Index » Profile for Steven J Gold » Messages posted by Steven J Gold
Go to:   
Powered by JForum 2.1.8 © JForum Team