I've recently purchased a new mac mini with a 256 GB solid state drive. I'd like to keep that drive as clean as possible and only have applications, system files, etc. No music or media. For all the other files, I've purchased a 4TB drive that I've set to Raid 0 for speed. I also bought a 3TB drive that I plan to use a backup for selected files on my raid drive.

I was thinking of partitioning my 3TB drive into 2 sections (1) being 256GB and (1) being the rest of the HD and having SuperDuper create a clone of my mac mini drive on the 256GB drive. For the bigger partition I was thinking of having QRecall backup my user folder and selected folders on my Raid drive (media, documents, etc.)

I'm looking for suggestions and opinions on this setup. Also, should I use 2 separate archives, 1 for my raid drive and 1 for my users folder?

Thanks.

Adam,

Here's my two cents:

Adam Horne wrote:I've recently purchased a new mac mini with a 256 GB solid state drive.

Congratulations.

For all the other files, I've purchased a 4TB drive that I've set to Raid 0 for speed.

I assume that you mean two 2TB drives that you've RAID'd together.

I also bought a 3TB drive that I plan to use a backup for selected files on my raid drive.

I was thinking of partitioning my 3TB drive into 2 sections (1) being 256GB and (1) being the rest of the HD and having SuperDuper create a clone of my mac mini drive on the 256GB drive.

Mirroring of your 256GB SSD to a second partition is, by itself, a poor backup strategy. There are excellent reasons for mirroring your startup volume, but as a backup it's not robust. You eventually end up with two scenarios:

You mirror your SSD automatically (say, daily). If something gets messed up and you don't discover it before the next mirror, you just end up with two copies of an OS that's messed up.

You mirror manually. This will eventually result in a mirror that's way out of date with your startup volume. If you mess up your startup volume, your backup is now weeks or months out of date.

With that in mind, here's my suggested setup:

Configuration
Set up QRecall to capture everything (your entire SSD and your media volume to your backup partition) to a single archive. I can't think of any reason for creating two archives.

The OS will actually be a small part of that archive, but will give you the ability to regress back to any recent version of your OS, applications, mail, preference files, etc. (not just yesterday's or last month's).

Space management
Since you're capturing (potentially) 4.25TB into a 2.75TB volume, you run the risk of filling it up quickly.

You can enable compression if space on the backup partition starts to get tight.

You could exclude non-critical media files (like music or movies that you have backed up on CD/DVD elsewhere).

Thanks for the advice James.

One more question....

I've used QRecall for a while on my iMac. Is there anyway to continue to use that archive? Or should I just create a new archive? Much of my files and folders were a copy over onto the new Mac Mini. It would be good cool if I could continue to add to the archive and just add the new actions for what we discussed.

Adam Horne wrote:I've used QRecall for a while on my iMac. Is there anyway to continue to use that archive?

Absolutely. QRecall archives are designed to store items for multiple volumes from multiple systems.

Simply set up your new computer to capture to the same archive. You can repurpose your existing QRecall actions simply by selecting a new target archive location in the your action documents. If you're setting things up from scratch, just choose the existing archive when you run the capture assistent on your new system.

A new volume will appear in the archive. Navigate to that volume to browse or recall items on your new computer. If you're using a different identity key, that volume will appear under the new owner.

Much of my files and folders were a copy over onto the new Mac Mini.

Since most of your documents have already been captured in the archive, capturing your new system won't cause the archive to grow much, since the majority of the data will be duplicate.

It would be good cool if I could continue to add to the archive and just add the new actions for what we discussed.

QRecall is very cool.

Thanks James

One more question...

I have another hard drive (we'll call it HD3) that is the backup to the backup...

I want to copy my archive over to HD3 a few times a week. It seems a little dangerous to make an archive of an archive, but what do you recommend?

I use Chronosync a lot and can have my archive sync over, but I'd hate for it to sync that large file over and over. Is it possible to have Chronosync "dissect" the archive and see whats changed?

What do you recommend?

Thanks James.

Adam Horne wrote:I want to copy my archive over to HD3 a few times a week. It seems a little dangerous to make an archive of an archive, but what do you recommend?

I don't know about "dangerous"?I have a couple of archives that I archive regularly. I would describe it as "cumbersome" because to recover something one must first recall the archive, then open that archive to recall the files.

The fundamental problem you're going to run into is that there's no way to sync a large file without reading the entire file and/or making a copy of the entire file, every time you sync. It's the nature of synchronization programs.

Most synchronization programs performs syncs in one of two ways. The simple way is to compare the two files (by looking at their modification date or actually reading both files) and then duplicating one of them if they are different. The end result is a copy of the entire file.

More sophisticated ones (like rsync) read the data blocks of each file, generate a "fingerprint" (checksum) for each block, and then compare those fingerprints. If they match, the blocks are the same. If not, the non-matching blocks are copied. This might seem to be terribly efficient, but most implementations work by first making a duplicate of the original file before modifying it, and then deleting the original. This is the safe way to synchronize the two, but doesn't save any data copying. The result is that the entire file still gets copied every time, and also requires that you have twice the amount of disk space as the file.

Making an archive of the archive is actually the most efficient. QRecall uses technology similar to advanced synchronization programs, but in a different way. The archive database already stores the "fingerprints" of all the data blocks already in the archive. So it's possible to capture the blocks that haven't changed without having to physically read or duplicate the unchanged data. Only the changed blocks need to be copied, and that's exactly what QRecall does.

My advice is not to do either. If it's a drive connected to the system you're backing up, simply create a second set of actions to back up your same items, using a much more leisurely (once/twice a week) schedule. You don't gain anything in terms of security or efficiency trying to backup the backup, this method is easy to recover from, it's just as safe as the "daily" archive, and it's ultimately more efficient.