Automated backup to network volumes

Hello,

I have implemented several Qrecall backup systems at client networks. I have noticed a difference in behaviour depending on choices made using the assistant:

When creating an automated backup strategy, the assisant asks if you have a permamently attached disk or a volume which is 'occasionally connected'. When I choose 'permanent' and then designate an archive on a networked volume, the scheduled backup (f.i. daily) mounts this volume if it is not already present, and backups fine. If I choose the second option, it does not do this although the script indicates this should be the choice when using networked volumes. What happens is that the backup waits until the volume is manually mounted and then proceeds.

2 questions:
- I want backups to run automatically so i want the behaviour of the first option. Does this work on all networked volumes? I only tested it with leopard server afp volumes, and got some errors on an older tiger server system.
- I can't see this difference in the script when opening the action list and compare the scripts. There seems to be no way to modify this setting?

Thanks

Stefan Robbers wrote:When creating an automated backup strategy, the assisant asks if you have a permamently attached disk or a volume which is 'occasionally connected'. When I choose 'permanent' and then designate an archive on a networked volume, the scheduled backup (f.i. daily) mounts this volume if it is not already present, and backups fine. If I choose the second option, it does not do this although the script indicates this should be the choice when using networked volumes. What happens is that the backup waits until the volume is manually mounted and then proceeds.

That's correct. When the assistant detects that the archive is on a removable or networked volume, it asks a few additional questions.

If you answer the question "Yes, Archive is on a removable volume", QRecall then asks when you would like the capture to occur. The schedule the assistant creates is based on these two questions.

If you say the volume is not always available and the capture should occur at a particular time, QRecall adds a "Hold while no archive" condition to the schedule. This causes QRecall to start, but immediately hold, the action until the volume containing the archive is connected. The idea is that the QRecall action will appear in the Activity window at the appointed time. If the volume is not on-line, this acts as a prompt for the user to connect the device or network, allowing the action to proceed.

This configuration is intended for users who have a laptop that isn't always connected to a network or a removable backup device that isn't always connected to the computer. QRecall will start the action at the given time, gently prompting the user to connect the backup device or network if needed.

If you ask QRecall to perform the capture when the archive volume is connected, it creates an event schedule that doesn't start the action until you connect the volume.

This configuration is good for people who regularly remember to connect their backup storage device or log into their network volume. This is an "opportunistic" strategy that starts a capture as soon as the user connects to the device or volume, rather than waiting for a particular time.

If you say that the archive volume is always connected, QRecall doesn't add any conditions to the schedule and runs it at the appointed time. If any action starts and the archive cannot be found, QRecall will attempt to mount it.

2 questions:
- I want backups to run automatically so i want the behaviour of the first option. Does this work on all networked volumes?

It should. The location of the archive is stored in a standard Mac alias record. When a QRecall actions started, the alias is resolved. For items on remote volumes, this should automatically mount the volume that contains it. For this to happen automatically, the network login information for that volume must have been saved to the user's keychain, the user must be logged in, and the keychain unlocked.

I only tested it with leopard server afp volumes, and got some errors on an older tiger server system.

It should work with all AFP volumes. Mounting is a function of the client, not the server. Auto-mounting volumes via an alias has worked since System 7, so I don't expect any problems as long as the previously mentioned conditions are met. If you have problems, refresh the alias in the action by opening it, re-selecting the archive, and saving it again.

- I can't see this difference in the script when opening the action list and compare the scripts. There seems to be no way to modify this setting?

It's under "Conditions" in the action's schedule.

The actions created by the assistant are regular actions. Feel free to customize them once the capture assistant has done its thing. There are several other possible schedules and schedule conditions that you might find more suitable.