Advanced backup topics

This is all stuff that most people don't need to worry about, unless the network section applies to you. Especially partial backups.

Backup in a network environment

If your workplace has a local area network (LAN) such as Netware, Lantastic, or Windows NT/2000-based networking, your network administration people will probably have provided some system-wide support or planning relating to user backup, and you should find out what it is. You should have the opportunity to test any backup system occasionally, by doing a test restore of a dummy file; see the acid test topic on my main backups page.

On some systems, they actually have server-based hardware and software that roams the network after hours, and backs up the contents of the local disks on workstations. This obviously requires that you leave your workstation running overnight.

Some network implementations provide server drive mappings for departments or individuals or both, encouraging use of those "drives" for routine storage of documents, rather than users' local drives. ("Local drive" in this context means a drive that's inside your PC.) User files stored on the server are much easier for network support to back up.

People sometimes find this system alarming at first glance from a privacy perspective. However, you should probably consider anything on your PC's local disk to be public information within your organization anyway, at least potentially. Ignoring questions of remote access for the moment, there's no reason why management can't and shouldn't simply walk into your office and turn on your PC, if the need arises.

A more significant objection to server-based user data drives: if the network quits working, you lose access to all your documents. Of course, the network-guy answer to this is "our network is always up."

This is also the common fundamental problem with currently trendy Microsoft .Net, so-called "Network Computers" in the Nineties, diskless workstations in the Eighties, and mainframes and "dumb terminals" back in the Stone Age: if the centralized system quits, your personal computing hardware turns into a doorstop.

It seems ridiculous to me for a PC with its own processor and mass storage to become useless just because the network goes down. Every so often PC people get together and beat this idea to death with a stick, but centralization seems to keep mutating and coming back.

Of course, there are a couple of ways you can fix this issue and still make use of your personal "drive" on the server:

  1. Use your server drive as a backup drive. Configure all your applications to save to a local-drive data tree (i.e. the default C:\My Documents\*.*) and make a batch file that copies the whole works to your server drive on demand. In Windows 95 and later, you can make a Desktop shortcut to your personal network "drive," and right-drag and Copy the entire contents of your My Documents folder to it to back up. Your stuff will then get backed up from the server by network support as they planned, but you won't be inconvenienced if there's a network problem. You'll be even safer if you can somehow automate the backup copy process, instead of needing to remember to do it manually every day.
  2. You could work it the other direction: set up your personal network "drive" as your default save location, and periodically copy it to My Documents on your local disk. This seems backwards to me. If you've done some work between your last backup and when the network quits, you'd lose access to your latest changes. Depending on how fast your network is, you may also notice a speed difference between saving to the server versus saving to local disk.

I like the #1 local-disk method better: you get maximum save speed, and your routine methods of working don't need to change during a network downtime incident; all that happens is your daily automated backup widget would produce an error.


Grandfathered backups

You can deepen your defenses even more by grandfathering your backups. Here's one approach: set up eight sets of backup media, four sets labeled "Monday" through "Thursday," and four more labeled "Friday #1" through "Friday #4." Use each set on the day it's labeled for. On Fridays, rotate the four Friday backups from week to week. Note the date on each Friday backup (yellow stickies work well for this). After four weeks of this, you will have at hand daily backups for the preceding week, and the last month's worth of Friday backups.

There are lots of possible variations; some people "grandfather" by months as well as by weeks, for instance. And yes, I think it's an odd expression too, but that's what people call it.


Archive and delete old files

If you're backing up to diskettes, and you reach a point where you feel there are too many diskettes in your backup sets and backup starts to seem like too much of a chore, there are things you can do to reduce the number of diskettes. For me, anything over two diskettes per backup set becomes annoying; it's a personal comfort-zone thing.

If your data files go back two years or more, you may be able to make your backups smaller simply by archiving and deleting old files. You might choose to make a backup of all data files which have not been modified in, say, a year, and then store that backup away securely and delete those files from your hard disk data tree. PKZIP, commercial backup programs, and XCOPY on the command line all have settings that allow you to do this easily.


Special purpose data trees

You may have certain projects that you work on sporadically; you put in some hours on it, then set it aside for a few days and come back to it. You may want to set up the data files for a project like that in their own special purpose directory tree, and only back it up when you've done something to it. "Directory tree" means any specific subdirectory plus all subdirectories that are "under" it.

Say you have a database project you're working on, a sales contact list. You could have a directory tree called C:\Contacts for the database project, and keep everything else in your standard My Documents directory tree. This is especially appropriate for database and graphics-related projects, because they tend to have large data files.


Partial backups

(Backup for masochists)

Partial backups are another approach to reducing the number of disks in any one backup. This topic gets too complicated to fully address here; I'm just going to hit the high points.

A partial backup is when, instead of backing up all your data, you only back up the files that have changed since a previous backup. Partial backups make most of your backup sessions shorter, at the expense of making your whole backup system a lot more complicated.

There are two systems for partial backups:

Incremental partial backup
You back up what's changed since your last partial backup. Incremental partial backups are a bit faster than differential partials, but you have to keep your last full backup plus all your incremental partials since, and a file to be restored might be located on any one of those backup sets.
Differential partial backup
Each partial backup contains everything that's changed since your last full backup. With the differential technique you need your last full backup plus the most recent differential partial.

PKZIP, commercial backup programs, and command-line XCOPY all have settings you can use to do those things. (PKZIP has limits on how much data it can handle at one time.) In both cases, as you can see, you have to hang on to more backup sets to be covered. Sometimes several partial backups can be placed sequentially on a single disk or tape cartridge. Partial backups always involve the annoyance of having more than one place to look when restoring a file, more so with incremental partials.

If it sounds to you like partial backups are a pain, I'd say you're absolutely right.

In fact, the use of these methods with diskettes in the early days of PCs may account for a lot of the negative attitude people tend to have now about backing up in general. I'd recommend that you not mess with partial backups unless you are absolutely forced into it for some reason.


HTML checked
site feedback