Because it manages so much of your service operation, you'll quickly find yourself becoming dependent on ServiceDesk in a degree that might be considered dangerous—dangerous in the sense that if you happened suddenly to suffer a catastrophic loss of data (i.e., if the fileserver's hard disk were to suddenly crash, with no backup), you'd be lost, severely handicapped in the ability to continue functioning with your normal degree of panache and flair.
As any seasoned computer user knows, there are many systems on the market designed to provide a periodic backup of critical data. Typically, such systems are setup to do a nightly backup of files onto a magnetic tape or writable CD. Certainly, you might consider using such a system to regularly backup your ServiceDesk files. However, besides involving substantial investment in hardware, these systems suffer other limitations which make them potentially less than adequate for the needs of a ServiceDesk environment.
The first problem is that a nightly backup will not save data until after the business day has ended. So, what happens if your fileserver's hard disk crashes around lunch time? Obviously, you will have lost data pertaining to the entire morning's work. This includes all the Callsheets regarding incoming calls that morning, all the JobRecords regarding jobs created and dispatched, all the PostVisitReports from techs regarding jobs done the preceding day, all the entries regarding parts used, replenished, and/or ordered, all the entries regarding sales completed, even the list of jobs scheduled in what was its current state (with additions, deletions and changes since the previous night). Obviously, there's a lot of important data to lose from such a short period of time, and the task of attempting to reconstruct it (and attempting to continue uninterrupted operation in the meantime) might be formidable.
The second potential problem is that, to save media, most backup systems are setup to write new backups over old. Thus, Wednesday night's backup may write over Tuesday's, and so on. To see why this might cause trouble, suppose one of your personnel, working in the Windows File Manager, inadvertently corrupts one of the ServiceDesk files (like the one containing a record of all your past sales, for example). Suppose this isn't noticed right away. You all go home at night, with your ServiceDesk directory containing a corrupted copy of the file, and your backup containing the only remaining good version. Then, precisely when programmed to at midnight, your backup system turns on and copies the corrupted file, writing it over the one good backup. Now, suddenly, you have no remaining good version of the file.
SD-Backup is designed to address both these problems, for any system or network that has any additional hard drive, besides the primary server, available. Installed on the secondary drive (typically from a satellite station in the network, but potentially from a second drive within the primary machine), SD-Backup will make copies of ServiceDesk files once per hour, once per day, once per week, once per month, and once per year. Each of these categories of backup will write into its own sub-directory, over-writing previous backups within its own class, but never over the backup from another. Thus, the most you'll lose from a fileserver hard disk crash (which, by definition, you'll certainly know of immediately) will be one hour's worth of activity (on average, the loss will be only 30 minutes). And, in the event of file corruption that's not detected for at least an hour but less than a day, you'll still have the daily backup to fall back onto (losing up to 24 hours worth of activity in regard to that one file, but no more). If the corruption is not detected until even the previously good daily backup is copied over, you'll still have the uncorrupted weekly backup to use (losing no more than a week's worth of activity on that one file), and so on.
It goes without saying that absolute data security would be even better, but in the real world, complete security for moment-by-moment activity does not yet exist. The SD-Backup system provides the next best thing. Of course, it has to be running to do anything at all. To run it, simply click on the SD-Backup icon from the station where you want your backups located. Then, leave it running in the background, full-time, permanently. Thus, you'll assure continual protection for your files.
We should mention, incidentally, that while there is no strict rule requiring that you use SD-Backup, you'd be most foolish to risk running without it. You'll become so dependent on ServiceDesk, security of its data becomes paramount. As any experienced computer user can tell you, "things happen." SD-Backup is effortless, silent, and very gentle on computer resources. Please see that it's properly running, and that it's kept so.
In the event you actually suffer data corruption or loss, your next task, obviously, will be to secure recovery from your backups. This, essentially, involves locating the uncorrupted backups, and copying them back over, into the appropriate directory, on your primary FileServer drive (or onto a newly appointed FileServer if your former one has catastrophically crashed).
One of the considerations, in this regard, is that before you copy any particular backed-up files over formerly working ones (or into a newly appointed FileServer drive), you may want to first review them for accuracy, lack of corruption, state of currency or not, and so on. ServiceDesk has a terrific built-in feature, for this purpose, called ViewBackups.* Access it from the File section of the MainMenu, or by pressing Alt + F1. As the name implies, its function is to allow you to view any ServiceDesk data in any of the various (i.e., hourly, daily, weekly, monthly or yearly) backup locations. You are required simply to select the drive and directory for the backups you want to see—after which each ServiceDesk form behaves just as it normally would, except now they are each accessing data from the selected backup directory, to allow you a full review of any file you are interested in. The one difference, you'll notice, is that the Menu bar flashes endlessly in this mode, and in an abnormal color, all to continually remind that you're viewing backups, and not regular ServiceDesk files. To return back to regular file access, either select ViewBackups again (MainMenu or press Alt + F1), or assent to changing back when ServiceDesk so suggests (as it does once each minute).
This feature is also handy, occasionally, even when you haven't had a file corruption or loss. For whatever reason, occasion may arise when you want to see what some file (or the data that goes in a file) looked like yesterday, last week, or whatever. It's easy to find out with this utility.
Once you've determined that any particular (or all) normal operating files need to be replaced by one or more backups, the next task is to copy the desired backup (or backups) into the appropriate location. At present, ServiceDesk has no built-in utility for this purpose—meaning you must use Windows Explorer, FileManager, or DOS commands to accomplish the task.
Remember that all the primary operating files, for ServiceDesk, are kept in the \sd\netdata folder of your FileServer drive (see Chapter 11.B: Directory and File Structure). Any other files (in other \sd\ sub-directories) can either be reproduced with some ease, or are relatively unimportant (except the backups themselves). It is, specifically, the contents of the \sd\netdata folder that SD-Backups will be making regular copies of. If a particular operating file becomes corrupted, it is that file, in this location, that must be replaced (i.e., copied back over with a good backup). Use whatever Windows utility you're most comfortable with.
