Dr.Backup Release Notes - Version

Transcription

1 Dr.Backup Release Notes - Version This version introduces several new capabilities into the Dr.Backup remote backup client software (rbclient). The notes below provide the details about the new capabilities and other changes to the Dr.Backup software. Improved Support for Open Files When backing up files that are exclusive (write) locked, we will now use the Windows operating system service called Volume Shadowing. This service should be enabled by default on all platforms from Windows XP SP2 through Windows Server 2008 R2 (All editions including "Foundation"). The VSS-based open file backup will replace the Visionworks Open File Agent (OFA) previously included in releases through Note: In general, it is ALWAYS better to backup a data file when it is closed by all applications. A snapshot of the current contents of a file on disk is called a "crash consistent" backup. This is what is provided (same as previously with OFA) for normal locked data files. If Windows provides a "VSS Writer" for a specific set of application files, then the writer will cause the application to flush its internal memory buffers thereby providing the backup application an opportunity to obtain a clean, closed file backup. Additional Information: 1. Only files on DIRECT ATTACHED STORAGE can use the VSS Open Files service. This is same as previous OFA. No mapped drive or NAS device support for open file backup. 2. VSS support is built into the rbclient and will generally always be enabled. If for some reason we do NOT want it to run (i.e., slow I/O system), there is a registry setting which can disable it. 3. VSS is NOT supported on W2K. For this platform only, we will continue to use v which will become the legacy support version. If we run into a machine where VSS is not working (excluding Server 2008 R2 which is not reliably supported by existing OFA) we may also use v or a special build with VSS disabled and OFA enabled. 4. Easiest way to see if VSS is working on a machine is to open up an admin command prompt and type: VSSAdmin List Writers 5. Internal implementation of VSS open file support differs between 32 and 64-bit machines. On 64-bit machines, a special service called "Exchange Backup Agent" is loaded which bridges the gap between rbclient (32-bit app) and VSS, a 64-bit service. As you may have surmised, this service also provides Exchange Message Store backup capability. We generally do a custom (optimized) version of this for our clients and don't use this standard service - however, it is required to be running for generalized VSS support on 64-bit machines. 6. After software installation, VSS Open File Agent support is automatically ACTIVE. No reboot required to activate this feature. Hint: When doing an update of software on a 64-bit machine, stop the "rbscheduler" service AND the "exchange backup agent" service using the "net stop..." command from an admin command prompt. If you don't stop these services, chances are you are more likely to need to reboot machine post update. 7. Files on direct attached storage open by an application for exclusive write will be "shadow copied" and that shadow copy backed up by rbclient. However, files with restricted permissions

2 (generally found on Windows servers) may NOT back up until the permissions are adjusted i.e., either SYSTEM priv or User priv is required to read the file (or read & write if using archive bit selection method) 8. The VSS service does require buffer disk space in order to create the shadow copies. This space is managed by the VSS service itself. Additional temporary storage and working space is used by rbclient in its own temp area. VSS, like OFA, does have an impact on performance - since disk I/O is increased. To minimize the time VSS is active, the rbclient will attempt to do VSS snapshots in batches i.e., it processes 100 files, then loops back and does VSS copies on the open files found in that batch. It then exits the VSS snapshot, freeing up the resources, and then repeats the process with the next 100 files. This minimizes the time VSS is buffering end user I/O on disk volumes. On most modern systems, you won't know its running unless the machine operates at a high I/O load. 9. VSS is supported directly by Microsoft. If there are problems with the VSS service itself, Microsoft online knowledge base and patches are available for all platforms. VSS "writers" (if available) provide stable backups (vs. crash consistent backups) and are supplied by the application provider, not Dr.Backup. 10. Even though it is technically possible to backup applications like SQL using the VSS within the client, it is still preferable to use the SQL plug-in which provides additional management and restore capabilities which would otherwise need to be performed manually on a VSS file based backup. The rbclient SQL plug-in also provides a crash-consistent backup by using the SQL server itself to ensure all databases are flushed to disk - something VSS may not do in all cases with SQL, especially on earlier server operating systems which do not include an SQL VSS writer. 11. On some systems, you may see an Event Logger error for VSS (ID=8194). The description of the event will point to an issue with the System Writer. Dr.Backup does not use the System State VSS writer, so this error can be ignored. Microsoft reports that this error message may occur on systems that use the certain versions of Microsoft Office or its associated libraries. Improved Support for Mapping NAS Devices In previous versions, when backing up files on external NAS devices, it was necessary to run a pre-backup script. This script created map drive definitions required for the rbclient to interrogate the files on the external storage. While these scripts provided the capabilities necessary to complete the backup, they required that the end user credentials be the same on the local machine as those on the NAS device. Otherwise, "Net Use" commands in the pre-backup scripts would need to expose the account name and password used on the share in the clear - causing potential security vulnerability in some instances. Also, mapped drives that were removed from the customer environment would cause rbclient backups to stall until adjustments were made to the pre-backup script. This problem was sometimes very hard to diagnose. The latest version of the Dr.Backup client software now permits the definition of private drive map definitions. Once set, they are permanently defined in the client and no pre-backup scripts are required. Additional Information:

3 1. The management interface to create drive map definitions private to Dr.Backup is found in the rbclient under Options > Network Drives. 2. The interface is fairly intuitive to use. Click Add to add a drive map. You will need to supply the drive letter (no colon required), the share name (e.g., \\ \public\share, Set Enabled to TRUE to activate the drive map, Username and password valid on remote share (NAS device). Leave the disconnect drive button checked and press Finish. After defining the drive maps, you will need to restart the rbclient. Hint: It is generally advisable to map the internal Dr.Backup private drive names to be the same as those used interactively by users. When defining the private drives, if you chose the same drive letter as an existing user defined drive, you may get a "System 85/86" error dialog box. You can safely ignore this diagnostic. 3. Once you have restarted the rbclient, you should see the left pane of the selection window now shows the mapped drives in an available status. If you see any drives with red X's on them it simply means that drives are locally mapped and have not been accessed recently. Clicking on a Red X will generally make the drive contents visible. However, ONLY DRIVES MAPPED EXPLICITLY by Dr.Backup are available to run in the task scheduler as background jobs. 4. When using network drives mapped within Dr.Backup from the Task Scheduler, the job MUST HAVE A USERNAME AND PASSWORD with login credentials that permit the end user to run batch jobs. You CANNOT RUN A BACKUP REFERENCING EXTERNAL DRIVES USING THE LOCAL SYSTEM ACCOUNT. If the user does not currently have a Username/password, then they must add one or you need to reconfigure all backups to run interactively as jobs from the system tray and not directly from the Task Scheduler. 5. When updating the Dr.Backup software, in addition to saving the backup.mdb catalog and any pre- or post- script files, if mapped drives are used, you must now also save the rbnetuse.ini file. This file contains an encrypted version of the drive map settings including the NAS device Username and Password credentials. 6. If credentials change on the NAS device, the changes in username/password must be adjusted inside of the Dr.Backup client software. If the password changes on the client machine itself, then the windows task scheduler settings must be updated inside of the Dr.Backup Schedule dialog box. 7. If you want to permanently remove a drive map from use, it is necessary to actually edit the rbnetuse.ini file and remove the unwanted settings. A bug inside of the Network Drives dialog box prevents the Delete option from working properly. However, in most cases, this is irrelevant since a non-existent NAS device will simply fail to map and the backup will continue without required intervention. 8. Creating network drive maps from WITHIN the rbclient application, does NOT make these drives available to interactive users or even visible from My Computer. Likewise, when using network drive maps, you must explicitly make all mappings within the Network Drives dialog box. Just because a drive map appears in My Computer does not mean that it will be visible to a backup job running from Task Scheduler. Event Logging using Microsoft Event Logs Dr.Backup provides extensive logging of all backup operations using its own internal log files stored in the folder \program files\remote backup. In addition, end users receive summary messages each time that a backup runs to completion.

4 Furthermore, if a backup account goes inactive, or backups run empty (no changed files) for a prolonged period of time, message notifications are sent and ultimately follow-up phone calls are made by customer support to advise the client. All existing reporting and logging will continue to remain in place with this release, and we will now provide basic logging using the Windows Event logs. Many clients are now moving towards a model where their IT consultant provides outsourced management/monitoring of their equipment and software applications. These consultants have requested that Dr.Backup write high-level summary information to the standard Windows Event log so that general purpose manage platforms (e.g., Kaseya, Level Platforms, Zenith) can routinely report basic backup status - or the lack of backup status messages. The rbclient has been updated to write status messages to the Applications Event log. The source of these messages is tagged as Dr.Backup v<versionid>. Events are written for the start of the rbclient, the completion of a backup and the shutdown of the backup program. In addition, the event status will be updated from informational to warning if a file backup fails due to locked files or if folders previously backed up are no longer found on the client PC. Certain rbclient program-detected errors are now also copied from the Dr.Backup application log file to the Windows Event log and reported with appropriate event codes. Other Miscellaneous Changes The following additional changes are being introduced in this version. While they will not require any change in end-user configuration, they are reported here for informational purposes. 1. Network Timeouts - If the remote backup client cannot communicate with the offsite storage servers, a timeout condition occurs. Previously, the rbclient would wait 5 minutes and then attempt to reconnect. Since most failures are short and transient, the retry timeout has been lowered from 300 seconds down to 60 seconds (1 minute). 2. Queue Limit - The rbclient operates on files in "batches." During processing, a number of files are copied from their location on disk to the Dr.Backup temporary working folder. The current number of files in a batch is 250. This number is being reduced to 100 in an attempt to lower the amount of temporary disk workspace required on the Dr.Backup "temp" volume. 3. Unnecessary Files Automatically Excluded - The files "desktop.ini", "thumbs.db" and "pagefile.sys" are files which we frequently find included in end user backups. These files are data files, however, no purpose is served in backing them up since they are created and updated automatically by the operating system. Therefore, a default global exclusion will now block the attempted backup of these files. 4. Disk space Threshold for Bitbackup - Since version 10.0, Dr.Backup has monitored the amount of free disk space on the volume where its "temp" storage is located. If the amount of free space drops below 1,000 MB (default), the rbclient processing is halted. This prevents the backup from depleting the disk storage on a PC that has little free disk space remaining. Since Bitbackup (differential file) backups can also consume large amounts of semi-permanent disk space, the Disk space threshold value will now also be enforced on the volume where the bitbackup cache is located. 5. Encrypted versions of Usernames and Password entered into the windows Task Scheduler dialog box are now maintained inside of the rbclient catalog. When updating software, the

5 backup.mdb file has sufficient information to re-enter all previous jobs (including associated username and password) into the Task Scheduler queue. It is no longer necessary to re-enter these names each time a software update is performed. Note: The new network drive feature uses a file called \program files\remote backup\rbnetuse.ini. This file along with any pre- and post- script files must be copied and replaced back into the program folder after the software update is completed.