Hi,
I am in the process of testing how to best back up a network of machines using QRecall.

So far all the stumbling blocks have been external to QRecall (like Mac OS 10.5 formatting a 4 TB drive correctly but later unable to write to it consistently, ending with Drive Utility trashing the volume and all the data on it).

I have set up a couple machines (4 or 5 right now) to back up to a central Mac OS X 10.6 server, using a 4 TB drive exclusively dedicated to the process.

Standard users are all backed up to a single QRecall archive file (to maximize disk space savings from all the identical Mac OS files) while "special" users with unique setups each get their own archive.

Now I have three questions:

1) "Standard" users every now and then don't execute the daily backup run - QRecall patiently shows "waiting for archive" even when the volume with the archive is mounted and the archive visible in the Finder and no other machine uses the archive. Restarting the machine generally seems to solve the issue but that obviously misses the backup window at night. Is this a result of several machines sharing the archive file? Is there anything one can do to avoid the issue?

2) "Special" users sometimes (but not always) have trouble mounting both the network volume and their dedicated sparse image file. Restarting or manual mounting seems to solve the issue but I wonder if there is a better way to do things.

3) I noticed QRecall having trouble on Mac OS X 10.5.5 (odd crashes) but working well on Mac OS 10.5.8. We are dependent on specific OS versions due to legacy software for certain tasks. Are there any older versions of QRecall available that could operate using 10.5.5 or even 10.4?

As always, thanks for your quick help. It is what makes implementing your software a real joy!

Dr. D wrote:1) "Standard" users every now and then don't execute the daily backup run - QRecall patiently shows "waiting for archive" even when the volume with the archive is mounted and the archive visible in the Finder and no other machine uses the archive. Restarting the machine generally seems to solve the issue but that obviously misses the backup window at night. Is this a result of several machines sharing the archive file? Is there anything one can do to avoid the issue?

QRecall uses the standard OS X sharing modes to detect if another process has a file open for reading or writing. It won't update (capture to) an archive if any other process is currently reading or writing the files in that repository package. You can use the lsof command line tool (on the server) to determine which process has the archive file(s) open.

More than likely, it's going to be the file sharing server process. A network file servers opens file on behalf of its network clients. What sometimes happens is the client momentarily loses its connection with the server. The server then leaves those files open forever, because there's no client to tell it to close the file. (When the client reconnects, it looks to the server like a new client.) All subsequent capture operations are then stymied by the phantom user that's keeping the files open.

Stopping and starting the file sharing process will usually resolve this situation. But that will also kick off all of the network users, which is a hassle.

2) "Special" users sometimes (but not always) have trouble mounting both the network volume and their dedicated sparse image file. Restarting or manual mounting seems to solve the issue but I wonder if there is a better way to do things.

QRecall mounts network volumes using the standard OS X alias resolution functions. Most of the time this works, but sometimes it doesn't. If network communications are a tad dicey (which they might be, given your first question), then it's a crap shoot. I used to have this problem all the time on my local area network, but recently it's been working flawlessly. I can't tell you why.

3) I noticed QRecall having trouble on Mac OS X 10.5.5 (odd crashes) but working well on Mac OS 10.5.8. We are dependent on specific OS versions due to legacy software for certain tasks. Are there any older versions of QRecall available that could operate using 10.5.5 or even 10.4?

Honestly, QRecall barely supports 10.5.8. Very little serious testing has been done on 10.5, and the next version of QRecall will drop support for PPC systems, bringing the minimum OS version requirement to 10.6.

You're welcome to try older versions of QRecall on your 10.5.x machines. If your archives haven't gotten too big, you can probably downgrade all the way to version 1.2.0 without running into compatibility issues. QRecall archive maintain compatibility flags, so it's always safe to try an older version of the application. If the format of an archive is not compatible with the running version of QRecall, QRecall will report that and refuse to perform the operation. There are different compatibility requirements for the actions, so a version might be able to read and recall from an archive, but not capture to it.

If you try to downgrade, you must uninstall QRecall before installing the older version. QRecall will automatically upgrade its components, but it won't downgrade them.

Thanks for the quick response, once again!

I will look into DNS issues to see if there is anything to be improved. Since Mac OS X 10.5 the lack of reverse naming schemes in a local network makes Mac OS X file sharing slower/trickier than necessary (many users coming from 10.4 knew this as the slow login effect, for example).

Other than that, everything is on wired Ethernet with no disconnects on other (sensitive) network operations, so hopefully my hunch works out!

Concerning older QRecall versions, where can I find those, please?

Dr. D wrote:Concerning older QRecall versions, where can I find those, please?

Sorry, I forgot to mention that.

Go to the Release Notes page. (You can also get to the release notes from the Download page.)

Next to each set of release notes is a download link for that version.