Sorry if this has been answered, but I did search and can't seem to find an answer. Rather than determine the answer empirically, I thought I would ask the author directly, since his answers are always clear and I assume more accurate than my guesses.



I would like like to use QRecall to backups to an archive stored on a NAS unit.

For various (compelling) reasons I would prefer to have the archive housed in a sparsebundle based volume which is mounted "locally" over NFS to to computer being backed up. So to QRecall the archive is just a local volume. I can easily script the mounting of the NFS/sparsebundle combo in cron or with a pre-run script hook if QRecall support those.


Questions:

a) Have I explained this well enough, does it make sense ?

b) Does the archive volume even have to support any Apple-centric (HFS) features. What features does the volume need to support.

Andrew Reid wrote:I would like like to use QRecall to backups to an archive stored on a NAS unit.

In general, there shouldn't be any problem. There are numerous QRecall users who backup to various NAS devices.

For various (compelling) reasons I would prefer to have the archive housed in a sparsebundle based volume which is mounted "locally" over NFS to to computer being backed up.

Just be aware that you'll be giving up some performance. NAS adds volume access overhead, and a sparse bundle adds more on top of that.

Also be aware the disk full situations could be a problem. Some NAS and sparsebundle implementations "lie" about how much free space is available on the volume. QRecall uses the volume status information to determine when an archive has filled up the volume so it can stop the capture and gracefully close the archive. If the volume lies, the archive could overfill the volume, damaging the archive and making it difficult to repair.

So to QRecall the archive is just a local volume. I can easily script the mounting of the NFS/sparsebundle combo in cron or with a pre-run script hook if QRecall support those.

Depending on your NAS implementation, QRecall may do this for you already. If the volume mounts as a networked volume, or appears (at the disk driver level) to be a physically connected external drive, QRecall will attempt to mount the volume/drive before an action begins. If QRecall mounted the volume, it will then attempt to automatically unmount it when all of the actions have run. Assuming the drive is compatible with the OS X's network volume or disk arbitration framework, this work has already been done for you.

a) Have I explained this well enough, does it make sense ?

It all seemed perfectly reasonable to me.

b) Does the archive volume even have to support any Apple-centric (HFS) features. What features does the volume need to support.

QRecall makes as few assumptions about the filesystem that the archive is located on as it can. So it should work on any filesystem that OS X supports.

It is, however, still being accessed via the Core Services framework in OS X. Apple has deprecated this framework and QRecall is currently being rewritten to use only the low-level BSD filesystem APIs. This should provide even better compatibility with foreign filesystems in the future, but for now QRecall has problems with some filesystems that aren't compatible with the Core Services APIs. For example, QRecall can't currently store an archive on a ZFS volume from TenOne at the movement because of quirks in the Core Services framework.

James Bucanek wrote:

...

Andrew Reid wrote: b) Does the archive volume even have to support any Apple-centric (HFS) features. What features does the volume need to support.

QRecall makes as few assumptions about the filesystem that the archive is located on as it can. So it should work on any filesystem that OS X supports.

It is, however, still being accessed via the Core Services framework in OS X. Apple has deprecated this framework and QRecall is currently being rewritten to use only the low-level BSD filesystem APIs. This should provide even better compatibility with foreign filesystems in the future, but for now QRecall has problems with some filesystems that aren't compatible with the Core Services APIs. For example, QRecall can't currently store an archive on a ZFS volume from TenOne at the movement because of quirks in the Core Services framework.

Thank you for your prompt and clear reply. The NAS's I wish to use vary widely from VM based ones to ones having a ZFS underlying filesystem. None of them are Windows based and very few of them are OS X based, so I wish to get off that treadmill of finding a netatalk version which works with a particular vesrion of OS X. Your system with the archive in an opaque (not a criticism) container seems to help this.

I will test out the software I will try the archive on a NFS volume with and without the sparsebundle and report back.

The sparse bundle has appeal as it can be encrypted, and it allows for network efficient offsite backup of the archive . I did read the note about caution in using encrypted sparsebundles as archive volumes, can you expand a bit on that ?


Thanks again, this looks like a very well engineered product.

Andrew Reid wrote:I will test out the software I will try the archive on a NFS volume with and without the sparsebundle and report back.

I look forward to hearing what you discover.

The sparse bundle has appeal as it can be encrypted, and it allows for network efficient offsite backup of the archive . I did read the note about caution in using encrypted sparsebundles as archive volumes, can you expand a bit on that ?

Sparse bundles add another layer of complexity to the filesystem that I prefer to avoid. In theory, it shouldn't make any difference. In practice, layering filesystem technologies like this can cause strange behavour that's difficult to track down.

In my latest post about sparse bundles, a user was getting strange archive verify errors. I was encouraging them to abandon the sparse bundle and use the volume directly?reducing the complexity. As it turned out, the volume/drive itself might have been the cause of the problem. They switched to a different drive and was able to write and verify the archive. I haven't heard back from them, but it probably wasn't the sparse bundle that was the problem.