Hi all,

Recently the technical support team has received questions about how BackupAssist handles manually entered scripts. In one such case, a user’s Robocopy script was causing a warning to appear in the backup report, even though the script was completing successfully. To explain why this warning appeared, and to answer other scripting-related questions, we’d like to outline how scripting works in BackupAssist, as well as show you how you can resolve the issue with Robocopy and other similar scripting commands.

Each script entered in the ‘Scripts’ tab of a BackupAssist job runs as a separate batch file. The “Run before each backup” script runs as one batch file, the “Run after each successful backup” runs as another batch file, and so on.

BackupAssist determines the success of each script individually, in the same way that Windows (DOS) does: the exit code of each batch file executed is the exit code of the last command in the script that modifies the exit code. While some commands, like echo, do not modify the exit code, the majority use ‘zero’ for success and a non-zero value for failure.

If BackupAssist detects a non-zero exit code from a script, the reporting option selected for the script will determine whether a warning or error appears in the backup report. In the job below, the script is set to add a minor warning to the report if the script fails:

If the above script returns an exit code of -1 (or anything except ‘zero’) when executed, a minor warning will appear in the report, similar to the following:

This is the default behavior for any script entered, but can be modified by changing the reporting option from “Minor warning” to one of the other available settings:

Now that we’ve explained how scripting works in BackupAssist and how the success or failure of a script is determined, we can discuss the Robocopy case mentioned. In this scenario, a user noted that a warning appeared in their backup report for a Robocopy script even though the script completed successfully.

The reason for this is that Robocopy does not use a ‘zero’ value to indicate success. Robocopy instead uses ‘zero’ to indicate two things: 1) that there were no errors AND 2) that nothing was copied. Non-zero return values from Robocopy can have many different meanings, including that the script completed successfully. For example, an exit code of ‘1’ indicates that files were copied successfully. You can visit http://support.microsoft.com/kb/954404 (Microsoft website) or http://ss64.com/nt/robocopy-exit.html (3rd party website) to learn more about Robocopy return values.

To handle Robocopy commands in BackupAssist you need to first decide whether the Robocopy operation is a critical part of the backup. If it is, you should change the reporting option to report an “Error” instead of a “Minor warning” if BackupAssist detects that the script failed (i.e. the exit code was a non-zero value). You can then modify your script to have BackupAssist report the Robocopy exit code so that you can identify real errors by checking for an exit code of 8 or higher.

You can then make sure that when the script runs successfully (i.e. the exit code returned is less than BackupAssist receives an exit code of zero. This will mean that no script warning or error will appear in the report unless the error code returned is 8 or higher. An example script to achieve this is as follows:

robocopy <arguments>

echo robocopy %errorlevel%

if errorlevel 8 exit

exit 0

We hope this information helps clarify how scripting works in BackupAssist, as well as how you can modify your job to handle different scripting programs. If you have any questions please email us at support@backupassist.com

Hi all,

With the continued development of the Centralized Monitoring Console (CMC), we’ve encountered some unexpected issues that we’ve had to help customers resolve. I’d like to share one such issue just in case you’ve been experiencing it on your server and haven’t been able to find a fix.

In one case we discovered that BackupAssist was generating an event with the following error on multiple servers, all on the same network:

Input String was not in correct format.

First, we checked to see if BackupAssist was communicating with the CMC server successfully. After performing a trace route test we discovered that the transmission was being sent, but that it was not making it to the CMC server itself. This led us to investigate security settings configured on the network to see if they might have been blocking the transmission.

After a few basic network checks, we tried disabling the anti-virus software (McAfee in this case) to see if this had any effect. We ran a test backup to trigger sending a backup report out, and lo and behold, the client received the report in their CMC account! After running through a few of the other servers experiencing this same problem, disabling the anti-virus software again did the trick and resolved the issue.

There was one server, however, where disabling the anti-virus application didn’t resolve the issue. After checking that there wasn’t another firewall or network security application installed, we tried browsing to the CMC server using Internet Explorer to see if it was accessible from the machine running BackupAssist. We readily discovered that the security certificate for http:\\secure.backupassist.com\cmc (the CMC homepage and the address where CMC transmissions are sent) was not listed as one of the trusted sites on this machine’s Internet Browser. After adding http:\\secure.backupassist.com\cmc as a trusted site in Internet Explorer and manually installing the security certificate, we were able to send reports to the CMC server successfully.

The steps to manually install security certificates can be found at http://www.niu.edu/its/internet/certificate/ie_help_file.shtml.

Adding a website to the trusted sites list within Internet Explorer can be achieved by completing the steps outlined at http://surfthenetsafely.com/ieseczone7.htm.

Important note: While McAfee was the culprit in this instance, other anti-virus software could cause the same problem. Unfortunately the customer experiencing this issue was unable to determine which setting in McAfee was causing the transmission to be blocked. As we do not advise completely disabling your anti-virus software, for the obvious reason of network and data security, we recommend that you try adding BackupAssistService.exe as an exception in your firewall application. This will hopefully prevent transmissions from being blocked. If you discover that another setting in your anti-virus software was the culprit for this issue we would appreciate it if you could let us know at support@backupassist.com so we can share the information with others.

For further reading and troubleshooting suggestions on the CMC, please take the time to read http://www.backupassist.com/education/articles/make-the-most-of-backupassist-centralized-monitoring.html.

I hope this helps,

Tim

Hi all,

Just a quick note to let you know that we have added a brochure for the BackupAssist for Rsync product to our website. It’s a concise four page brochure that outlines the advantages of Internet backup, and offers 10 reasons why BackupAssist for Rsync is an ideal solution for your Internet backup needs. The document is intended to introduce new users to the BackupAssist for Rsync product, rather than to be used as an instructional or technical guide.

You can download the brochure here or access it from the Rsync product tour page or the brochures page.

If you have any queries either about the brochure or Internet backups in general, as always, please contact our support staff at support@backupassist.com.

To all our clients,

As you may be aware, due to an issue with our web-hosting provider, the BackupAssist website has been unavailable for the past several hours. The problem has been rectified and all services on our website should be available.

We want to thank all our valued customers for their understanding during this difficult period. We sincerely apologize for any inconvenience caused to you, and have appreciated your patience while we have worked with our provider to return the website to normal operation.

If you have any questions or concerns, please email us at support@backupassist.com.

Hi all,

We had a support issue recently where a client of ours was using a 3^rd party imaging product, and then using the BackupAssist Zip-To-Tape Add-on to transfer those images to Tape.

Unfortunately, there was an incompatibility with this setup.

The 3^rd party imaging product implemented its own VSS Provider, which in turn meant that standard calls to VSS from other backup software (such as BackupAssist) failed. It appears that the 3^rd party imaging VSS Provider assumes that it is the only backup software installed, and will stop other backup software from working.

Also, BackupAssist incorrectly reported that the backup succeeded. (This is being fixed and will be released in the next version of the software.)

 The workaround: If you are using BackupAssist to transfer a backup to tape or other location, you can turn off VSS in the backup job by following the steps below:

1. Launch the BackupAssist console
2. With the console started select “Edit” from the console’s drop down menu, then click the job name corresponding to the Zip-To-Tape backup job to access the job settings
3. From the job settings, select “Open files” from the left-hand tab menu to display the “Open file options” page
4. Un-check the tickbox called “Microsoft Volume Shadow Copy Service” then click “Apply changes” in the bottom, right-hand corner

Please note: we regret the inconvenience, but the incompatibility is caused by the other 3^rd party software causing standard Windows VSS functionality to break. Once installed, there’s nothing that BackupAssist (or any other software that uses VSS) can do about it.

Linus

Hi Everybody,

This is a quick post to let everyone know that our Australian office will be unavailable from Friday 12th – Monday 15th March, 2010.
This means that there will be no phone support and minimal e-mail support available during these times from our Australian office. The reason for this is due to relocation of the office and also major server maintenance.

Our US office will be available from 9am – 5pm US Eastern time as usual and can be reached on 812-206-4265.

We apologise for any inconvenience caused by this downtime.

Kind Regards,
Stuart
Lead Help Desk Engineer – Australian Office

Hi everyone,

I’ve just wound up a tour around Australia of the SMBiT Groups – Sydney, Adelaide, Brisbane and Melbourne. Needless to say, I was absolutely exhausted by the end of it – getting up at 4:45am to catch a flight from Brisbane, or sitting for an hour on the runway at Sydney airport is very taxing!

I spoke about various topics, but the major one was about correctly backing up Hyper-V.

It was absolutely fantastic to meet you all, and I hope that you all got a lot out of the meetings. The feedback has been tremendous, and the questions I was asked during the meetings were highly intelligent.

Over the next few weeks, I’m going to blog about the major questions that were raised during the presentations so that we can share the knowledge.

A big collective thanks to everyone who attended, everyone who asked quetsions, the group leaders for welcoming me to your respective groups, and of course, the many resellers who I met. Your continued support of BackupAssist is really appreciated. And I received a lot of excellent feedback and feature requests – thank you so much!

Regards,

Linus

Due to some unfortunate networking issues, the UK and US Support teams are experiencing difficulties with their Email servers, and it has created a delay in response times for emails.

We are attempting to resolve this issue as swiftly as possible, and you should receive a response to your emails before Start of Business on Tuesday February 16th.

In the meantime, our support staff are still available via phone for any critical issues that need to be addressed, they can be reached on + 1 (812) 206-4265

How does Hard Links work with Single Instance Store (SIS)?

This is a question we get quite often because it is so different than traditional backups.

When doing either a File Replication or an Rsync for Windows job, using a schedule other than Mirror 1:1, you will be using the SIS.

The SIS uses Hard Links to allow a never ending incremental backup.
This means for any file that has not been changed, it will be marked so that it is not backed up.
The confusion comes in because in the past, an incremental backup would be smaller than the full backup, and you would need to have every backup made, since the last full backup, to do the restore.  Because of Hard Links each folder is really linked back to the unchanged data, so every folder appears to be the size of a full backup.  This allows you to restore all your data from the newest backup, even if older backups had been deleted.

Hard Links have the drawback that when you select all of your folders, your unchanged data will be reported for each folder, even though it was only backed up one time.  A 1MB file will show as 3MB if you are looking at 3 folders.  You will need to check the properties of the hard drive to see how much data has actually been written.  This also means if you copy the backup directories to another location,  the hard link be broken, but your data will be copied for each folder you have.
(more…)

Recently we  had a situation where a customer was only permitted to backup to a folder on the local hard drive of their SQL server..  If the job was written to another backup device/location, the job would generate a BA1505 error (Cannot open the specified destination directory from the server – it may not exist or the SQL server may not have the correct authorization).

After a little brainstorming,  we changed  the user account the SQL service was running to a domain administrator account instead of the local system account. Then it was time to test out the backup again (with fingers and toes crossed).
The result: The SQL server was successfully backed up to removable drives and other locations!

The explanation:
The trick with SQL is to remember that the “Use SQL authentication or Use Backup User Identity” option is simply to get access to *run* an SQL backup,  it does not give any privileges for the SQL server to *write* the backup anywhere.

The privilege for writing comes from the user account that is running the SQL service. By default this will be the computers Local System account (or similar).This account has high privileges on the local computer, with zero privilege on other computers,  therefore the UNC shares on remote computers will need to be writable by everyone *AND* the remote computer must have “simple sharing” *disabled*.  This is why we temporarily create a share on the BackupAssist machine with writeable-by-everyone privileges (if the SQL server is remote and the destination is a non-UNC path).

If the SQL service user account is changed to a domain account (not necessarily the backup user, but makes the most sense) then the UNC share needs to be writable by that account. Note that running the SQL service as a domain administrator is a security risk, as it  could permit any hacker that can connect to the SQL server the ability to  access domain admin privileges on the network.  Also, database applications running on the SQL server (eg. a website using the SQL server as datastore) may be affected if the SQL service user changes; e.g. a domain administrator contains a greater amount of permissions overall, however a local system account is given more specific permissions when running application services on a particular machine.

This is why we recommend setting up a share on the SQL server, that is *readable* by the Backup User Identity, and backing up to that share using a UNC path. This avoids changing the SQL server account and the potentially risks, and avoids permanently having a share writable by everyone. Another BA job can easily pick up the .bak files from that share, or the post-backup script could do the same.

For more information on the SQL add-on available with BackupAssist, please take the time to look over our white paper located at http://www.backupassist.com/downloads/whitepapers/SQL_WP.pdf.

Hopefully this information helps out when having permission issues such as we were!