This script (a type of computer program) backs up directories (a.k.a. folders). Why did I write a script to do something so trivial? I needed it for myself. On my main computer, I was backing up a multitude of folders with Windows explorer. This was error prone (I might forget to backup a directory) and time consuming. I copied one directory, waited for it to complete, then copied another. Often the directories took a long time to back-up which meant twiddling my thumbs at my computer. Then there was the other computer where I wasn't backing up anything . . . 

Backups have to be easy to do, or most people won't do them. With this in mind, my goal with this script was to make it as easy to run as possible. Towards that end, it can be configured for one click backup. That is, you can set up an icon on your Windows desktop for this script, click on the icon to run the script and that's it. It will do everything from soup to nuts without asking any questions or posing any prompts. There are other ways to run the script, and it can provide much information if you so desire, but my goal was the easiest possible backup to run. When I'm in the middle of doing something else and need to make backups, the last thing I wanted to have to do was think about the backups. 

The tradeoff is that it may entail some waste (backup some files that don't really need to be backed up) and there are fewer backup options compared to many other backup programs. For example, this script only backs up entire directories. It does not back up individual files. If you need to back up some files in a directory but not others, this is not the product for you. On the other hand, it can back up any number of directories.  

Almost everyone needs to backup files from multiple directories. You fall into this category if you don't keep every important file in the My Documents folder. It should be especially useful to people who need to back up different directories on different computers. Copy the script to each computer and customize it as needed. 

Even if you are brutally organized, and keep all your files in a single directory, you may still want to backup files in multiple directories. For example, you might want copies of your E-mail and web browser Favorites/Bookmarks. AOL users might want to backup the AOL download directory. If you use the Outlook calendar, you may want a copy of the file holding your schedule. Windows 2000 users might want to back up the WINNT/Repair directory. 

This script is most useful in cases where you are backing up files to a location that is large enough to store multiple copies of them. For example, if you were backing up 200 KB of files, you could fit 6 copies of your files on a single floppy disk. If you back up your files to media that can only hold one or two copies, then this script may not be your best option. 

The script is written in VBScript and intended to be run under Windows Scripting Host (WSH). For more on WSH, see the Get The Script section below. 

You control the action of the script by modifying configuration variables (a.k.a. controlling parameters) in the script. Like all scripts, this one is distributed as source code and can be edited with Notepad.  Below is a sample of these variables. The rest of this document describes the meaning of each of these variables in detail. 

 '**************************************************************
 '    Configuration Variables 
 '**************************************************************
 OutputDrive = "D"             'Output Drive letter
 dim sourcefolders(1)          'Define a list of 2 directories to be copied 
 sourcefolders(0) = "F:\FamilyPix"       'Back up this directory
 sourcefolders(1) = "C:\WINNT\repair"    'Back up this directory
 AutoOpMode = "no"             'Auto operations mode? Use "yes" or "no"
 MinBkupsToKeep = 3            'Minimum number of backup generations to keep 
 MinDaysToKeep = 8             'Minimum number of days to keep every backup generation
 OutputFilePrefix = "MikeBkup"      'File name prefix 
 LogComment = "Look ma, no hands!"  'A comment that is written to the log file
 SystemLogging = "no"               'Enable system logging? "yes" or "no"
 

As noted above, the script backs up all files in a list of directories. It can back up any number of directories and the directories can reside on any drive letter available on your computer. Each directory to be backed up has to be specified as a member of the sourcefolders array (an array in this context refers to a list of similar things). You do this by modifying the source code of the script as follows: 

  dim sourcefolders(2) 'Declare an array with three elements, the folders to backup 
  sourcefolders(0) = "C:\My Documents"   
  sourcefolders(1) = "C:\WINNT\repair" 
  sourcefolders(2) = "F:\anydirectory\subdirx" 

The sample above backs up three directories. The gotcha here is that when declaring or defining an array ("dim" in VBScript) the number of elements is one more than the number in the array declaration. This is because VBScript arrays start with element zero. In this example, the sourcefolders array is declared (the dim statement) to contain 2 elements, which Microsoft has decreed really means three.  

The script can reside in any directory on your computer. However, I advise against using the script to back up the directory that the script resides in. In general, not just with this script, backing up files that are in-use at the time they are backed up is a bad thing. 

The backups are normal files, that is, they are not created in a proprietary data format. It is as if you copied them with Windows Explorer. Restoring the backups is as simple as could be, just copy the desired files as you would copy any files. The script is not needed for restores. 

All files in the source directories are copied (this is typically referred to as a full backup). 

The output drive letter is specified in a configuration variable called OutputDrive as follows: 
    OutputDrive = "F"    'Drive Letter where output backups go 

This  causes the backups to be written to the F disk. In auto-operations mode (explained more below) this setting is used unconditionally. In manual mode, the user gets a chance to change the output drive letter at run time. 

All the backups created in a single execution of the script reside in a single backup directory. The backed-up directories end up as sub-directories of this main output directory (explained in the next paragraph). The main backup directory is created in the root directory of the output disk drive (F in the example above). The directory name will look something like: 
      F:\MikeBkup_Full_mmmdd.yyyy_hh.mm 

For example, a backup that starts on January 24, 2002 at 1:22 PM will create a backup folder called: 
     F:\MikeBkup_Full_Jan24.2002_13.22  
The hour and minute in the file name will always be two digits.  

As noted above, the directories backed up in a single execution of the script, end up as sub-directories of the main output directory. The input directory name is slightly transformed. To illustrate how, the directories specified above would cause the following to be created in the main output directory: 

The back slashes in the input directory names are changed to double underscores. This was done for two reasons. One was a technical issue with creating new folders from VBScript that I won't bore you with. The other reason was to make it very simple, clear and obvious which directories were backed up. Had I preserved the exact directory structure (for example by creating a repair directory under the WINNT directory) then it would not have been immediately obvious which sub-directories of the WINNT directory were backed up. The "My Documents" folder name was not changed at all because it was not a subfolder, that is, there were no backslashes in the name. 

Note that the source drive letter is not reflected in the output directory name. I didn't think it was all that important since the full name is documented in the log file, but I might add this at some time in the future.  

The script also creates a plain text log file of its activities. A sample of the log file is shown elsewhere on this page. Two copies of the log file are created. One copy goes to the same directory where the script is run from. If you isolate the script in its own directory, this provides a neat grouping of the script and all the logs of its activities. Old log files are not deleted. The other copy goes to the main output directory. 

Backups can only be written to devices that appear to Windows as a drive letter. If Windows Explorer can copy files to it, this script can write to it. Since writing to CD-Rs involves special software, the script can't write to them. It can write to USB based keychain flash storage devices and USB based external hard disks.

Every backup program has to deal with a profile of the files being backed up. The profile is the definition of the files to be copied along with all the options and parameters to use for the copy. Some backup programs refer to this as a backup set. 

Typically a backup program will let you define multiple backup profiles and handle them all. This script does not, it can only deal with a single backup profile. That is, you can only define one set of files/directories to back up and can only define one set of options/parameters to use with those files (more on this in the next topic). 

To implement multiple backup profiles, make multiple copies of the script. Name each copy appropriately and be sure that each copy of the script specifies a different value for the Output File Prefix.

The configuration variable, OutputFilePrefix, controls the file name prefix that is used when creating the log file and the main output directory. The default value is "MikeBkup" and this is what's used in examples on this page. Someone named Harvey can have their backups labeled HarveysBkups. This would result in a backup directory being created with a name like  F:HarveysBkup_Full_mmmdd.yyyy_hh.mm.

If Bill and Ted share a computer and want to have an excellent backup adventure, Bill can customize his copy of the script with the directories he wants to copy and an output file prefix of BillsBackups. Ted can customize a different copy of the script with his directories and an output file prefix of TedsBackups. Both Bill and Ted can run the backup script whenever they chose and keep as many copies of their backups as they like. Each set of backups is separate and independent due to the different output file prefixes. 

Backup profiles can also be used to back up directories at different times. For example, one set of directories can be backed up daily with one rule (number of generations and/or days) for how many backups to keep. Another set of directories, specified in a separate copy of the script, can be backed up monthly with a different rule for how many backups to keep. As long as each set of directories uses a different OutputFilePrefix, they are separate and independent. 

For example, suppose user Mo wanted to backup some files daily, user Larry wanted to backup other files weekly and user Curly wanted to backup still other files on a monthly basis. To accomplish this, set up three copies of the script as shown below. Again, it is suggested that all copies of the script reside in a single dedicated directory.   

The output file prefix can be any character string, but I suggest that "backup" or "bkup" be included for the sake of clarity.

Like any script, this backup script is distributed as source code. WSH scripts have a file type of VBS.  However, this script is distributed as a plain text file (.TXT) rather than as a VBS file for two reasons. First, anti-virus programs are on the lookout for VBS files because they can contain viruses. Second, you have to modify the source code anyway before it can be of any use to you. 

To view the script as a plain text file in a new window click here. Save it on your computer with  File->SaveAs  in your web browser. Then edit the configuration variables and changed the file type to ".VBS").  

Running the script requires Windows Scripting Host (WSH) version 2.0 or later. WSH is a component of Windows (it is the replacement for BAT files) that allows you to run scripts written in VBScript and JavaScript. WSH is included in Windows 98, ME, 2000 and XP. It was not included in Windows 95 and NT4 but users of those operating systems can download it, for free, from Microsoft. 

As of January 2002, the latest version of WSH is v5.6. The script was developed under version 5.6, but according to the Microsoft documentation, should run on versions as old as 2.0, which is pretty darn old. IE4 and Outlook 98 supported WSH version 3.0. The first version of IE5 supported WSH version 5.0. Windows 2000 comes with WSH version 5.1 (and updating it to SP3 does not update the WSH version). Windows XP comes with WSH version 5.6. 

As noted above, the script can run from any directory on your computer. However, I suggest keeping it a dedicated directory for two reasons. One, it avoids the issue of backing up the directory where the script resides. One copy of the log file is written to the directory that the script is running from. Isolating the script, also isolates these log files. 

---

If this is your first encounter with Windows Scripting Host, there are a number of ways to test if WSH is installed on your computer, and if it is, which version.  

Perhaps the simplest way is create a file with a file type of VBS (for this purpose, the file can be anything at all). Then view the file in Windows Explorer, using the large icons view. The icon shown here on the right indicates that it is installed.

When you run the script, the log file (below) includes a display of the version of WSH on your computer.  

As with all backups, you should shut down any applications for which you are backing up their data. For example, if you are backing up your email messages, then shut down your email program. Specifically, this script will fail if you try to back up Outlook’s data files while Outlook is running. 

The script runs in one of two modes: manual or Auto-Operations. Manual mode is intended for when you want to manually invoke the script. Auto-Operations mode is intended for use with scheduled backups where there is no person sitting at the computer. Typically scheduled backups are taken in the middle of the night.

The mode is determined by the AutoOpMode configuration variable. It should be set to either "yes" or "no" (it is case sensitive). "yes" means Auto-Operations mode, "no" means manual mode. 

The cheat sheet below illustrates the differences between manual mode and auto-operations mode. In Auto-Operations mode, the script asks the user no questions and displays no status messages while it is running. The automatic deletion of old backups only occurs in Auto-Operations mode. 

Running Manually

The simplest way to manually run a WSH script with a file type of VBS, is just double click on it in Windows Explorer. WSH scripts can also be run from a command prompt or you can create a shortcut on the desktop for the script in the usual way (right click on the file in Windows Explorer and select Create Shortcut). 

In manual mode, the user sees a number of prompts as described below. 

When this script finishes, the user is put into Notepad to view the log file. In manual mode, there is no automatic deletion of old backups. The log file shows all the existing backups and their fate is left to the user.  

Running Automatically via a Scheduler

Like any windows program, the script can be invoked by an automated scheduler program. Unlike most WSH scripts, there are no input parameters to worry about. All configuration options are specified by editing the source code of the script.  

Many flavors of Windows include a scheduling application. The following are instructions for scheduling this script using the scheduler in Windows 2000. 

First insure that the Task Scheduler service is running. Most likely you will want to set this service to run automatically at boot time (Control Panel -> Administrative Tools -> Services). Run the scheduler using the Scheduled Tasks application in the Control Panel. Double click on the option to add a scheduled task. Click on the Next button, then the Browse button. Navigate to the .VBS file that you want to schedule. Give a name to the scheduled task, select a schedule and a time (you can change these later), enter a username and password. After the script is scheduled, you can double click on the scheduled event to bring up more advanced scheduling options. As noted above, the first time the script is run (either by the scheduler or by you) NAV will complain. 

Be careful about the password when scheduling the script. If it is wrong, at least on my computer, there were no errors or warnings, the script just did not run. Nothing was logged to any of the three system logs. 

There is an option for scheduled events in Windows 2000 to "Wake the computer to run this task". I tried this with my computer sleeping (called Stand by mode in Windows 2000). The machine woke up and the scheduled backup ran. Cool. The screen remained black, but status lights indicated that it came out of sleep mode and that disk I/O was performed. I then tried it with the computer turned off. It stayed off. 

Norton Anti-Virus also has a scheduler, I have not used it to schedule backups. 

This section describes the other configuration variables and additional concepts and messages used by the script.

Automatic deletion of old backups:  To prevent backups created in Auto-Operations mode from growing forever, the script can automatically delete old backups based on both the age of the backup and the number of existing generations of backup. For an old backup to be automatically deleted: 

• Auto-ops mode must be on  AND
• There must be X newer backups (you set value of X) AND
• The backup must be at least Y days old (you set value of Y) 

The X above is controlled by configuration variable MinBkupsToKeep which determines the minimum number of backup generations to keep. If you set this to 4, for example, the backup script will not consider deleting old backups until there five or more backups. Whether the fifth or later generation of backup will be deleted, depends on the next variable. 

The Y above is controlled by configuration variable MinDaysToKeep that determines the minimum age of kept backups. For example, if you set this to 20, the backup script will never delete an old backup that is less than or equal to 20 days old. Backups older than 20 days may be deleted based on the value of MinBkupsToKeep. Note that if you specify zero for MinDaysToKeep the script will not delete old generations created on the same day the script is run. A backup made today is considered zero days old and this field specifies the minimum age, in days, of backups that are to be kept.

Both these settings are minimum values, there are no maximum limits. They were implemented to insure that a reasonable number of backups are constantly available. However, since backup generations that are over both minimum limits are deleted, these parameters also function to limit the amount of stored backups. 

The determination of which, if any, old backups are deleted by the script is based on satisfying all the above criteria. To illustrate this interaction between MinBkupsToKeep and MinDaysToKeep consider the following configurations: 

Note: When there are multiple old generations, all created on the same day, the script does not delete the oldest one first. I judged this as being too much programming for too small a payback (it requires re-sorting the backups by date and time). For example, if there were three backups made on Tuesday and as a result of applying the deletion rules, one of them needs to be deleted, it is a tossup as to which one will actually be deleted.   

---

Copy Speed: After a folder has been copied, the total elapsed seconds for the copy is calculated and externalized in the log file. If the copy took at least 4 seconds, then the speed of the copy operation is calculated. Small directories are ignored on purpose because the sample size is too small to produce useful speed numbers. The speed of the backup is shown as both bytes/second and MegaBits/second. The first number is useful as a point of comparison when backing up from and to a local hard disk. The second number is useful when backing up a computer on your LAN.  Are you really getting the 10 MegaBits/second the LAN was advertised  as being capable of? Probably not. Both these rates are externalized  in the log file.

---

Wasted Space: After copying all the source directories, the free space on the output disk drive is re-examined. This is done to compare the number of bytes that should have been needed for the backup to the actual number of bytes used. The bytes used is taken from the difference in the amount of free space on the output drive before and after the copy operation. This calculation gives you some idea of the wasted space due to poor cluster sizes. This waste/overhead will vary depending on the file system and the partition size. The worst case is a FAT partition of 2 gigabytes. This depends on the file size, the cluster size and the file system. It is not an issue with the script itself. I once ran a copy of 219 Megabytes of data to a disk drive that had 278 free Megabytes. The copy got only halfway though before running out of space due to extreme cluster size waste. Disk space wasted due to the cluster size is less an issue with FAT32 than with FAT and less with NTFS than with FAT32. 

---

Comments: To aid in documentation, there is a configuration variable called LogComment for user comments. The value of this variable is written out, unchanged, to the log file.

---

System Logging:  The concept of an Operating System log is usually only associated with Windows NT/2000/XP. However, WSH provides system logging capability under Windows 9x/Me also. Under Windows NT/2000/XP, WSH writes to the application log (as opposed to the system or security logs). It can be viewed with the Event Viewer (in Windows 2000: Control Panel -> Administrative Tools -> Event Viewer). Under Windows 9x/Me, events are logged to file wsh.log in the Windows directory. 

As of version 2.8, the script can write messages to the system log. Should system logging cause a problem, the configuration variable SystemLogging can be used to turn it off. A value "no" disables it, anything else enables it. It is highly suggested that a value of "yes" be used to enable it. As of version 2.9, the default is "no". This is because Windows 98SE, with its default of WSH v5.0, does not support system logging. Also, under Windows 9x system logging can fail if the wsh.log file is locked. 

At the start of script it logs all the configuration variables and the script name and source. At the end it simply logs the fact that it ended. If there is no end of script message, it died mid-stream. Eventually I might use the system logging feature to log errors, especially those involving creating the normal text file log. You can use the log data as input for a reporting system based on the system logs. 

Under Windows 2000, when the script is run manually (both in manual mode and auto-operations mode), the log file will show a source of "WSH", a category of "none", a user of "N/A" and an event of 4, which simply means the message is informational. I haven't yet tried system logging when running the script from the Windows scheduler.  

You could, of course, use a dedicated backup program instead of this script. For many people, this will be the right decision. This script however has some advantages. 

• The backups are normal files. The script copies files just as you would with Windows Explorer. The backup files are immediately usable. In contrast, some backup software, such as that included with Windows, stores the backup files in a proprietary data format which requires the backup program at restore time.
• The script is free. 
• It was designed to make backups while requiring the least amount of intellectual thought. This is especially true if you use automatic mode. 
• The script can automatically delete old backups using criteria you define. This lets you continually take backups and be insured that you always have the number of backups you want and not have to worry about old backups continually consuming hard disk space. 
• All the effort in using this script is up-front and should be one-time. Subsequent backups should be easy and when backups are easy to make, it's more likely people will do them. 
• It backs up multiple directories
• The script does extensive logging of its activities.
• The script automatically assigns, what I think are, good names for the backup files 
• The script can run either interactively (manual mode) and in batch mode (non-interactive, auto-operations). 
• The script reports on cluster waste and the speed of the backups. 
• It is easily scheduled using the Windows scheduler. 
• It may be easier to define a backup set (the list of directories to back up) with this script than with dedicated backup software. Of course, the definition of easier is subjective. 
• The documentation is reasonably thorough (you're reading it now) 

Then again, there are dis-advantages of the script 

• It does not back up to Windows "shares", that is, to a destination in the form of \\servername\shared_directory1. It only backs up to drive letters. Note though, that it can write to a CD-RW disc that is formatted with the UDF file system. Then again, so can any Windows program. 
• It does not do incremental or differential backups (the flip side is simplicity)  
• There is no GUI and editing the script using Notepad can be error prone 
• It only copies entire directories. You can not pick and choose individual files and there is no option to include/exclude subdirectories. 
• It requires WSH which may not be installed on old versions of Windows such as 95 and 98. 
• It does not compress the output backup files 
• It does not span a backup across removable media such as zip disks or floppy disks. Then again, in manual mode it will tell you the space needed for the backup and the available space on every drive letter. 
• Implementing multiple backup profiles requires multiple versions of the script. To me, this is not a big deal. 
• Backups are always created in the root directory of the output drive letter. For more on this, see the User Experiences section below 
• There is almost no error handling (it was my first WSH script). This has been a problem with files in use and files that generate a security error. The script stops cold. Perhaps I could have it continue, but it copies entire folders at once, not individual files. If it continued, that would still leave the folder with problem file, partially copied.  

WSH has been associated with viruses causing some people security concerns. Norton Anti-Virus 2001 and 2002 protect you against WSH scripts. From personal experience, I can say that NAV 2001 is particularly good at catching the execution of scripts. If the script blocking feature is enabled, and it should be by default, it pops up a window before a script runs. There are options to prevent the script from running, to let it run once and only once, and to authorize it to run all the time. The full authorization is lost if any changes at all are made to the script. 

For anyone not using NAV 2001 or 2002, there are options to partially disable WSH. In Windows 95 and 98 you can rename the main WSH executables (wscript.exe and cscript.exe) to prevent scripts from being run automatically. Desired scripts can be run by executing the renamed executables directly. In Windows 2000 you need to make extensive registry changes to do the same thing. I don't know about Windows XP.   

Symantec has an item on their web site called How to disable or remove the Windows Scripting Host that provides more background on this and offers a free program to enable and disable WSH. 

I know of two programs that can be used to to run the backup script and then shut down the computer. 

A free program called Timed Shutdown can shut down your computer at a specific time. If your backups take 30 minutes, set Timed Shutdown to turn off your computer in 45 minutes. I have not used this program and did not write it. It is for Windows 9x and 2000. 

Another free program, Karen Kenworthy's Show Stopper can be used to manually invoke a shutdown of your computer. It intercepts the shutdown and runs one or more programs, before letting the shutdown continue. Backup and Defrag before powering off! You can read about the program in her newsletter of March 11, 2003. I have not used Show Stopper but I have used enough of Karen's programs to vouch for her as an excellent source of good, free software. 

Windows XP users can schedule their computer to shut down by using the Windows scheduler to run program shutdown.exe. This is not available in older versions of Windows. 

The format of the log file name is MikeBkup_Log_mmmdd.yyyy_hh.mm.txt. For example, a log file created on January 26, 2002 at 1:22 PM would be called  MikeBkup_Log_Jan26.2002_13.22.txt. The hour and minute will always be two digits. A copy of the log is written to the directory the script is running out of. An additional copy is written to the backup directory. 

Backup to a folder
June 8, 2007. I have been meaning forever to modify this script to backup to a folder instead of simply a disk drive letter. In the mean time, you can use this trick from ghacks.net to assign a folder to a drive letter. It involves the DOS "subst" command. To make "f:\myfolder" appear as the G disk, do this: "subst g: f:\myfolder".

Delete Read Only
September 15, 2006. If a copied folder is due to be deleted based on one of the rules configured for the script, the delete fails if the folder is read-only. The script should check first to see if a folder is RO and, if so, zap it to RW so it can be deleted. Syntax is here: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/jsproattributes.asp  and here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/vaproattributes.asp 

Network Drives.
July 28, 2005. Currently the script only writes to disk drive letters, not to UNC paths. If you need this feature, it is possible to map an UNC path to a drive letter in the beginning of the script and then un-map it at the end. The following code is already in the script, in the beginning, in the section called "Common Objects": 
  Dim myNetworkObj
  Set myNetworkObj = Wscript.CreateObject("Wscript.Network")

All that needs to be added to map a network drive is something like: 
  myNetworkObj.MapNetworkDrive "Z:", "\\computername2\dirname3","True"

The "True" is an optional Boolean indicating whether the mapping will be persistently connected or not. In addition, you can provide a user name and  password for connecting to the other computer. To unmap the network drive use: 
   myNetworkObj.RemoveNetworkDrive "Z:"
Read more about the Network Object.  

---

May 28, 2005. If the total length of all the sub-directories gets too long the script fails with an error code of 800A004C. I'm not sure the longest length that Windows and/or WSH can handle. I have to test for a long name as it's being created and take some remedial action to shorten it. Perhaps just use single letters for sub-sub-sub directory names.

---

The error handling is non-existent. I need to modify the part of the script that actually does the directory copy to ignore errors during the copy. This way I can externalize an error message and copy any other later directories.

---

May 5, 2005. A user wrote asking for the ability to direct the output to a specific folder. Currently you can only direct your backups to, for example, the F disk (as in F:\). You can not direct them to a specific folder on the F disk (as in F:\MyBackups). I had been meaning to add this feature for a while. If you want this feature, I am pretty sure the below source code changes will work, but I have not yet been able to test it. 

In the section of code labeled "To Copy or Not To Copy" there is a line 
   outfoldername = OutputDrive & ":\" & OutputFilePrefix & "_Full" & filenamedate 

If you change this to 
   outfoldername = OutputDrive & ":\MyBackups\" & OutputFilePrefix & "_Full" & filenamedate 

then the script should write the backups to the MyBackups folder rather than to the root of the disk drive. If anyone tries it, let me know how it goes. One advantage of this is that when the backups are stored on an NTFS partition you can compress the backups without compressing other folders.
Update: May 12, 2005. A user of the script was nice enough to let me know that the above change does work. However, there is a missing piece - the script still looks in the root directory of the output disk drive for old backups to delete. I'll get to this.... 

---

One user of the script could run it manually without a problem, but had the exact same script fail when run by the Windows 2000 scheduler. The scheduled version of the script even ran with the same userid as the manually run version. The problem was with the output drive, a shared directory on his LAN that was mapped to a drive letter. This should work. Upgrading WSH to version 5.6 solved the problem. See Making a Script Work as a Scheduled Task from Windows Scripting Solutions June 2001.

---

Another user has a different problem with the Windows 2000 scheduler. Her backup scripts stop working each time the machine changed to or from daylight savings time. I have no idea why. 

January 24,2002  First GA version. 
January 25,2002 Added auto-operations mode for running the script by a job scheduler. In auto-ops mode no questions are asked of the user and no informational messages are displayed. Also added the ability to automatically delete old backups so that scheduled runs of the script don't blindly create more and more backups. This is done using two new configuration parameters, a minimum number of generations to keep and a minimum number of days to keep each backup generation.
January 26,2002  Added  a version number that is displayed on the first line of the log file. This is version 2.1 
January 28,2002 Version 2.2 Variable AutoOpMode used to be case sensitive. No more. Changed name of the log file. It used to start with "MikeBkupLog". It now starts with "MikeBkup_Log". Added a new configuration variable LogComment for user comments that are written to the log file. 
January 29,2002 Version 2.3 Added a new configuration variable that governs the file name prefix to be used when creating the log file and the main output directory. Previously the file name prefix was always "MikeBkup". Now this is merely the default. 
January 30, 2002 Version 2.4  Minor changes to the log file output. 
February 1,2002 Version 2.5 Changed home URL of this script
March 23,2002 Version 2.6  Added the force option to the folder delete command used to delete old backup generations.
May 24,2002 Version 2.7 
In manual mode, added a display of all available disk drives and their freespace. The user can now direct the backups to any available disk drive at run time without changing the script source code. As before, the user can still bypass the backups if, for example, none of the disk drives has sufficient free space. The new display is shown on this page in the Running The Script section. Other minor changes include: logging changes to reflect this new processing, added a count of the number of backup generations deleted (mostly of interest when zero), changed messages in the log to be more specific about why old backups were not examined for possible deletion, and renamed some variables. 
May 27,2002 Version 2.8 
Write to a system log to note start and end of script. At the start of script it logs all the controlling parameters and the script name and source. At the end it simply logs the fact that it ended. Also made a minor change to message displayed to user in manual mode at end of backup processing. Added new configuration variable SystemLogging which is documented above. 
May 28,2002 Version 2.9 System logging can be troublesome under Windows 98, so the default was changed from "yes" to "no". 
June 30,2002 Version 2.10 One bug fix, no new features. Under some circumstances (I can't narrow them down) there is a bug with the For-Each statement under WSH when looping through an array. I have not seen the problem when looping through a collection. The nature of the bug was that the loop continued past the end of the array resulting in a null variable rather than an array element. In effect, it was doing For-Each+1. There were two places in the script that used a For-Each loop to navigate the array of the source folders to be backed up. These loops no longer use For-Each. 
August 30,2002 Version 2.11 One bug fix, no new features. In making the changes for v2.10 the upper bounds of the array were not tested correctly. As a result, the script would not back up the last directory. 
January 14,2005 Updated comments in source code 
May 5, 2005 Updated comments with instructions for patching the script to send output to a directory. See User Experiences  

---

FYI: An article about making backups by Lincoln Spector in the February 2002 issue of PC World magazine

FYI: This script was featured in the August 26, 2002 issue of the Langa List newsletter. Fred Langa has a free and paid version of his newsletter. The paid version (referred to as "plus") is longer than the free (standard) edition. This script was one of the extras that readers of the paid version got to learn about.