I currently use Apple's Backup program to maintain an offsite backup of important files on dot Mac (soon to be mobileme), and I'm wondering if qrecall might do a better job. I'd like to check out some of the assumptions I'm making about how things work over a network, though, and get any other thoughts you might have before I try it.

Would the processing reduction gained by using smaller archives make it worthwhile to have separate archives for different groups of files, particularly for groups of files that I might want to update less frequently?

Capture compression should reduce the amount of backup data to be transmitted, but would it also impose additional interchanges between qrecall and the archive that would negate these savings?

Would merging and other management processes be inordinately time-consuming over the internet?

Do you have any other thought pro or con about using qrecall over the internet?

Ralph

Ralph Strauch wrote:I currently use Apple's Backup program to maintain an offsite backup of important files on dot Mac (soon to be mobileme), and I'm wondering if qrecall might do a better job.

Alas, .Mac/MobileMe and QRecall are not a good mix. There's a long-winded discussion about why in the Online storage thread. But the short version is this: MobileMe is based on WebDAV which does not play well with QRecall.

Would the processing reduction gained by using smaller archives make it worthwhile to have separate archives for different groups of files, particularly for groups of files that I might want to update less frequently?

Probably not. There's not much overhead associated with the data in an archive that isn't being updated. The overhead of managing multiple archives probably outweighs the overhead of a lot of data that doesn't get updated that often.

Capture compression should reduce the amount of backup data to be transmitted, but would it also impose additional interchanges between qrecall and the archive that would negate these savings?

Compress doesn't involve any additional communications. Overall, less data is transferred to a compressed archive than an uncompressed one. The penalty for compressing an archive is computational: Every time data is accessed from the archive it has be be decompressed and all new data has to be compressed. That just takes a lot of additional CPU cycles.

Would merging and other management processes be inordinately time-consuming over the internet?

Yes. The best strategy would be to avoid them, or run them very infrequently (like once a month), if your only connection to the archive was over a slow communications link.

Do you have any other thought pro or con about using qrecall over the internet?

If the file server you are storing the archive on is using a "real" remote file system protocol (like an AppleShare server) then you'll probably be OK capturing a modest amount of data and scheduling infrequent merge and capture actions.

However, if you are using any WebDAV based service (MobileMe, Amazon SSS, AOL, ...) then it's impractical to use QRecall on the remote archive directly. Instead, consider getting a small USB thumb drive or small external drive and performing your captures to that. Once a week, or once a month, upload the archive to your off-site data store.

Thanks for the explanations, James. I'm glad I asked before I set it up. I'll probably keep using Apple's Backup for the offsite backup. It does work, but is a far less elegant solution than qrecall.

Ralph