Mike's Backup Script

This script (a type of computer program) backs up directories/folders. Why did I write a script to do something so trivial? I needed it for myself. Backups have to be easy to do, or most people won't do them. 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 . . .

This script should be of use to people who need to back up files in multiple directories. You fall into this category if you don't keep every important file in the My Documents folder. Any shared computer probably needs this script too. It should be especially useful to people who need to back up different directories on different computers. In configuring this script for your needs, you specify a list of directories to be backed up and the drive letter where the backups should reside. Copy this 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. 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. Then there are assorted system files such as the registry or your web browser favorites/bookmarks. Windows 2000 users might want to back up the WINNT/Repair directory.

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.

This script backs up directories (a.k.a. folders). It does not back up individual files as I had no need for that and originally wrote the script for my own use. It backs 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. You do this by modifying the source code of the script as follows:

dim sourcefolders(2) 'Copy these folders to make a backups of them
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 an array ("dim" in VBScript) the number of elements is one more than the number in the array declaration. Microsoft says this is because VBScript arrays start with element zero. In this example, the sourcefolders array is declared to contain 2 elements, but it really has three.

For additional, optional, configuration parameters see the section below on Bells and Whistles. I'm not sure what happens if the script is running out of a directory that is being copied. It can't, however, be a good thing to do.

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. 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 however is slightly transformed. For example, the directories specified above would cause the the following to be created in the main output directory:
directory: My Documents
directory: WINNT__repair
directory: anydirectory__subdirx

The 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. 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.

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.

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 parameters and insure the file type is .VBS (you may have to rename it).

The script requires Windows Scripting Host (WSH) version 2.0 or later. WSH is the replacement for BAT files and is included in Windows 98, ME, 2000 and XP. Windows 95 and NT4 users can download it. It also gets installed along with IE5. 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 fairly 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. Windows XP comes with WSH version 5.6.

One way to see if WSH is installed on your computer is to try and run the script after renaming it to a .VBS file. If Windows does not know what to do with VBS files, WSH is not installed. If WSH is installed, the log file (below) will show you the version of WSH on your computer. The icon used for .VBS files also indicates whether WSH is installed. The icon shown here on the right indicates that it is installed.

You can also run the script below to see what version of WSH is installed on your computer. It displays the information shown here at the right. Copy the script source code below into Notepad. Save the file with a name of your choosing and a file type of "vbs". Run the script by double clicking on the file name from Windows Explorer.

Wscript.Echo "Name = " & Wscript.Name &vbCrLf &_
"Version = " & Wscript.Version &vbCrLf &_
"At " & Wscript.Fullname

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).

Assuming Auto-Operations mode (next topic) is turned off, the following describes what the user will see while running the script.

First, the script calculates the total size of all directories that are being backed up and the amount of free space on all available disk drives. All this is displayed to the user (see right) who can chose the output disk drive letter. The default drive letter is taken from the OutputDrive variable. By clicking on the Cancel button, the user can bypass the backup process altogether.

After each directory is backed up, a pop-up message is briefly displayed on the screen (see left) with the name of the directory and the time taken to back it up. There is no need to click the OK button, the window will close itself after three seconds.

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.

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.

Anti-virus Gotcha
If you use Norton Anti-Virus 2001with script blocking enabled (and possibly other anti-virus programs), the first time you run this script, NAV will popup an alert window. The script does a handful of things, such as creating the log file, that NAV does not like . If you select "authorize this script" you will be able to run the script repeatedly with no additional alerts from NAV, at least until the script is changed in any way (even if only comments are changed).

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

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.

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.

A 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.

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

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

Auto-Operations Mode: In this mode, the script asks the user no questions and displays no status messages while it is running. It is intended for use with a job scheduler for automated execution of the script. The use of Auto-Operations mode is controlled by configuration variable AutoOpMode which should be set to either "yes" or "no" (it is case sensitive). The automatic deletion of old backups only occurs in Auto-Operations mode.

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:

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.

Both these settings are minimum values, there are no maximum limits. They were implemented to insure that a reasonable number of backups were 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:

AutoOpMode = "yes" MinBkupsToKeep = 4 MinDaysToKeep = 2	If this backup script is run daily, this results in four generations of the backup being kept, the oldest of which is 4 days old. If the script is run weekly, this results in four generations being kept, the oldest of which is 4 weeks old.
AutoOpMode = "yes" MinBkupsToKeep = 4 MinDaysToKeep = 20	If this backup script is run daily, this results in twenty generations of the backup being kept, the oldest of which is 19 days old. If the script is run weekly, this results in four generations being kept, the oldest of which is 3 weeks old.
AutoOpMode = "yes" MinBkupsToKeep = 4 MinDaysToKeep = 31	If this backup script is run daily, this results in thirty one generations of the backup being kept, the oldest of which is 30 days old. If the script is run weekly, this results in five generations being kept, the oldest of which is 28 days old.

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.

System Logging: As of version 2.8, the script can write messages to a system log. 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). Under Windows 9x/Me, events are logged to file wsh.log in the Windows directory.

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. If there is no end of script message, it died mid-stream. While these may not be the most useful messages in the world, eventually the system logging function can be used to log errors, especially those involving creating the normal text file log. It might also provide input for an existing reporting system based on the system logs.

In case system logging should cause a problem, version 2.8 includes a new configuration variable SystemLogging which 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.

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.

Action	Manual Mode AutoOpMode="no"	Auto-Operations Mode AutoOpMode="yes"
Before the backup starts, the user is shown the available space and the required space and asked whether to continue with the backup	Yes	No
After each directory is backed up an information message is displayed	Yes	No
After the backup is complete, old backups are evaluated for possible automatic deletion	No	Yes
After the script is complete, Notepad is run to show the user the contents of the log file	Yes	No

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.

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.

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.

*** Mike's backup script started at: 1/26/2002 12:32:17 PM ***

Script: MikeBkup.vbs Version 2.11
Environment:
OS: Windows_NT Computer: NEWDELL User: Linda WSH version: 5.6
Running from: C:\somedir\MikeBkup.vbs by Windows Script Host
Comment: Look Ma, no hands!
Controlling parameters:
AutoOpMode=yes MinBkupsToKeep=2 MinDaysToKeep=2 OutputFilePrefix=MikeBkup
OutputDrive=F SystemLogging=no
Output drive:
F SHAREALL(Fixed) FAT32 Total Size: 1,621 Megabytes Free Space: 660.7 Megabytes
Input Folders to be copied:
F:\Mystuff\ToRead 4.1 Megabytes
C:\WINNT\repair 7.5 Megabytes
Total size of input folders 11.6 Megabytes
Created output folder F:\MikeBkup_Full_Jan24.2002_12.32

Copy starting...
Start F:\Mystuff\ToRead 1/24/2002 12:32:57 PM 4,280,940 bytes
    End F:\Mystuff\ToRead 1/24/2002 12:33:01 PM 4 seconds to copy
      Speed of copy: 1,070,235 bytes/second 8.2 MegaBits/second
Start C:\WINNT\repair 1/24/2002 12:33:04 PM 7,839,182 bytes
    End C:\WINNT\repair 1/24/2002 12:33:10 PM 6 seconds to copy
        Speed of copy: 1,306,530 bytes/second 10.0 MegaBits/second
Copy completed.

Output Drive Freespace: Before 660.7 After: 648.0
Backups that should have used 11.6 Megabytes, actually used 12.6 Megabytes
Searching for existing backup folders . . .
looking in root of F disk for directories starting with MikeBkup
F:\MikeBkup_Full_Jan24.2002_15.46 (11.6 Meg) 1/24/2002 3:46:16 PM
F:\MikeBkup_Full_Jan23.2002_20.16 (11.6 Meg) 1/23/2002 8:16:53 PM
F:\MikeBkup_Full_Jan25.2002_19.22 (11.6 Meg) 1/25/2002 7:22:42 PM
Search completed
Examining old backups for possible deletion...
Deleting F:\MikeBkup_Full_Jan23.2002_20.16 It is 3 days old. Limit is 2 days
Examination complete, 1 backup generations deleted.

*** Mike's backup script ended at: 1/26/2002 12:33:13 PM ***