As a recent post noted, Offline Files is still a temperamental technology that I have decided is not worth the effort on Windows 7. So what other systems can you use? Take note of the following:
-
By default, Windows 7 will create a restore point on the laptop’s hard drive every day. This can be used to retrieve a previous version of a file
-
Windows Backup can be used to make a backup of files onto an external HDD. However, it has very limited options, and I recommend considering the use of either an external disk with its own software, such as the Seagate Replica, or a third party program such as Karen’s Replicator from karenware.com
-
Commercial backup software such as MS DPM or Seagate BackupExec can have agents installed to automatically back up a laptop to a server, in conjunction with a server based installation of the software.
-
Robocopy can be run from a server to automatically back up using a script. In the rest of this article I will describe this option further.
Robocopy is a command line tool that has been available since the days of Windows NT and has been progressively refined since then. It is a powerful tool that we have used to do some of our backups up until now. There are many parameters and settings that can be used. The following is a list of these and how they are being used in the evaluation so far:
Source directory: typically \%1%2%3documents and \%1%2%3desktop are used (Robocopy is being invoked twice, once for each path). %1 is the Netbios name of the laptop. %2 is the sharename, %3 is the foldername within that share. Typically you will need to share the Users folder in Windows 7 or Documents and Settings in Windows XP, in which case %3 is also the Windows username of the user. To avoid visiting each laptop user, if you are the domain admin, use Computer Management to connect to each laptop in turn and then create this share. I use random strings of 20 characters followed by the $ sign to name each laptop share individually and keep it hidden. Grant Read permissions to Everyone on the new share. Windows file permissions will still prevent anyone other than the user and Administrators from accessing these files.
Target directory: Typically this might look like \servershare%3backupdocuments or desktop depending on the source directory as above. This makes use of a target folder based on the username of the user, which is the same parameter as was used on the source directory.
Filespec: I recommend you create a settings.rcj file and use it with the /JOB:settings parameter. In the RCJ file you place the option /IF on a line by itself and then one filespec per line thereafter. At the moment this will look like:
/IF
*.do*
*.xl*
*.md*
*.acc*
*.pp*
*.pub*
which will pick up most Office files. Add, delete or change to suit.
Other options: /R:45000 /w:1 /B /FP /V /S /MIR /MT /TEE /LOG+:%3.log. Put the rest of these except the last (log) option into the RCJ file (one per line). Specify the log on the command line.
/R: /W: specify a retry option and wait between retries (in seconds). The settings shown wait for up to 12 hours. The recommendation would be to run this with Task Scheduler and get it to force termination at a lesser interval than the frequency you are running this on (e.g. 20 hours if you are running daily) and adjust the retry count as appropriate.
/B will try to use Backup mode if you don’t have the full file permissions set up for backup. /FP, /V and /TEE are logging settings. /S is for copying files in subdirectories. /MIR ensures that the backup mirrors the source. This option deletes files on the target if they are deleted from the source, so it isn’t the setting to use if you want to guard against file deletions. /MT makes Robocopy use multiple threads. /LOG is used to create a log file, the + option appends to an existing log file of the same name.
The actual calls to Robocopy are contained in our case in a Robobackup.cmd command script. I write an individual CMD file for each laptop and set up Task scheduler to start this, in the cmd script it makes the call to Robobackup.cmd passing in the parameters specified. The idea is one backup per day in a 12 hour window. But you could be more versatile and try for three backups each in a 4 hour window. I am still tweaking our test environment to see what we can do, and I expect a few different options will be tried out, and these might also include turning on Shadow Copies on the server where the backups are being stored to see if it will keep previous copies.
In the end I changed R and W to 0 and taskscheduled my task to run 12 times a day, every hour. This sounds like a lot and might well prove to be, but given that laptops will not be connected a lot of times, and that it will quit immediately if it is not, the amount of traffic probably won’t be as much as one would think. Another option is to trigger if the laptop is connected, but this requires a custom script or other means to detect connection (pinging would achieve this).
UPDATE: Task Scheduler seems to have problems when it starts a command script that starts another command script that finally runs Robocopy. There also seem to be problems with a command script that has more than one command line in it.
After a lot of trial and error, therefore, my scheduled task is calling a cmd script that runs Robocopy directly using parameters that are passed into it. The task action passes four parameters into the command script that specify the laptop name, share name, username and folder for the source path. One of these also specifies part of the destination path, and another specifies another part of the destination path and the name of the log file. There are two task actions for each user, which arrange to back up the Desktop and Documents folders respectively. The common settings are passed in a .rcj file. There may be a fifth parameter to specify the rest of the destination path once I get my head around where these backups are going to be stored.