Very Old! Probably does not work anymore
AVImark contains a lot of information that is critical to any veterinary practice. It doesn't take much to see that it is necessary to do regular backups of Avimark. But for anyone who has tried to simply copy the Avimark folder and run the new copy, they know that this doesn't work. This document details some of the tricks we have used to get a reliable nightly automated backup of Avimark working.
Disclaimer: I am in no way affiliated with Avimark. I don't even really like calling them, as they tend not to be very helpful. I am also not responsible for your copy of Avimark, so if you break it trying any of these things, don't come to me. That said, nothing here says anything about deleting your data, really all you are trying to do is copy it. So I think it would be pretty hard to really damage anything. If you really don't want things to go wrong, do a backup with the built in backup program first and save it somewhere else.
As a system administrator who has been in charge of a medium sized network for an animal hospital for almost 10 years, one of my most critical tasks is making sure that there is regular working backups of Avimark. But Avimark is a tricky beast. A simple backup program generally can't capture a copy of Avimark, as when Avimark is running certain files cannot be accessed, or are in an inconsistent state.
Our practice is open 24/7, but thus far we have not found any way to make a reliable automated online backup of Avimark. Avimark comes with a tool for a manual offline backup. So far we have found that tool unsatisfactory and have developed our own system for automated backups.
We run AVImark in a relatively complex environment. There are multiple physical locations, Avimark is accessed through network shares, but primarily via thin client as a Microsoft Terminal Services connection. Our Avimark folder is rather large, surpassing 20gb without any of the medical imaging files. Even a simple copy takes on the order of 4 hours, and operations like rebuilding the indexes takes 8-10 hours.
Despite these complexities, we have come up with a relatively simple system that takes about 10 minutes of offline time to perform our nightly Avimark backup.
This tutorial discusses some of the tricks we have used to get a reliable fast backup. My hope is that people comment with their own experience and tips.
Note: A lot of the backup problems we have are because of Avimark's database format. For several years Avimark has been promising a SQL based version. I hope that when they release that, all of these problems will go away, and backup should become as simple as any other SQL server based backup. But until that happy happy day:
The biggest thing that saves us from a long down time to backup Avimark is using an increment backup. That means we just copy the changes to Avimark that have happened since the last backup instead of making a full copy each time. This works really well for us. After an initial full backup (takes a whole night), our nightly backup only takes about 10 minutes to sweep all the files, figure out which have changed then copy them into our backup.
Most any backup program (including the windows built in one) has an incremental backup feature. For completeness, we use a program called SecondCopy. We used several more complex and expensive programs for a while. SecondCopy has been more reliable and took me far less time to figure out. It is also pretty cheap compared to most other backup programs.
Update: We started having problems with the windows backup program. It backs up fine, but when you try and restore any files the live copy avimark stops working during the restore. I would assume this is because the windows backup program is locking the originals while it restores. In our case a restore took 8 hours, so it was not acceptable to have Avimark down for that long to get at archived backs. The most common usage was just to restore a backup to check something, so the downtime was excessive. We have since switched to a program called Retrospect for all of our incremental backups.
This problem we experienced embodies one of the golden rules of backing up: restore your backups regularly to see what is there. Your backup wont be of use to you if they don't work when you need them. In Avimark this means opening the program, making sure that something you put in during the previous day is there. Poke around in the program a bit. We had a backup running for a long time where Avimark would open fine, but the inventory didn't work anymore. Only by testing the backup extensively were we able to find this out.
One nice feature of our SecondCopy backups that we have found indispensable is that it actually leaves the copied files as a simple folder. They are not in any sort of backup format or archive etc. So we can just open up our backup folder, then open any one of the backed up Avimark folders and use that copy. This allows us to go back to old working versions when the need arises. (Un)fortunaltly we use this a lot.
For a backup program to successfully make a copy of Avimark, that works later when you try and use it there has to be no one using the system. In a small practice, I assume that means yelling over your shoulder "hey everyone, shut down your Avimarks for a little bit". This does not work in a large practice though, so we have developed some scripts that block access for everyone. At first we used windows batch files, but as our system got more complex, we switched to python. If your not interested in figuring all this out yourself, you can buy the scripts off of me. Or if I find enough competent developers who would like to help me with new features, I will open source them.
net send /DOMAIN:vet System backup is starting... Avimark will be unavailable until the backup is finished.'
Firstly we use the windows "net share" command terminate the Avimark share. This will stop people from accessing the Avimark over the share. We don't have enough people using Avimark over the shares anymore for me to worry about starting a remote domain wide shutdown of the avimark process before closing the share. Although its probably a good idea to do that if you have lots of people using the share, because I would assume its not good for the databases if you close the share while people are writing to the Avimark folder.
net session /delete /y net SHARE avimark /delete
On a terminal server, there will be several people logged into the machine using avimark. First thing we do is use the windows messenger service that comes built into widows to send a message to all the users in the system notifying them that the backup is going to be starting. Then we use a command line tool to gently shut down all running copies of avimark. the tool can be found here. The command
process -q avimark.exeterminates all processes on the local system that are called avimark. The "-q" send a quit command instead of a hard process kill. If avimark is at the login screen, this exits the program, if a user is using the program this brings up the "are you sure you want to quit" box. We then delay a moment, then issue the same command again with the -k option, forcing any avimarks that didn't close gracefully to terminate no matter what they are doing. At this point there should be no more avimarks running on the local machine.
While the backup is in progress we don't want anyone using Avimark, so the easiest thing to do is rename the avimark.exe file. When the backup is done, it is renamed back to avimark.exe. So during this time, any shortcuts that may point to Avimark will not work. That is exactly what you want so someone doesn't open an Avimark during the backup time and muck up the whole thing.