www.aiscl.co.uk

I had some auto backups run over the weekend. I wanted to see the logs and when I selected the jobs (there are 4) and clicked on the Log tab, I see the following message for every job:

Exception: EstringListError: List index out of bounds(-1)
Component: fAquariusBackup
Exception: EstringListError: List index out of bounds(-1)
Component: AISPanel2

What is this and why can't I see the logs?

There are 4 jobs that run over the weekend, each with a different destination folder. I have them setup as autorun so they kick off one after the other. I checked the destination drives and I see .zip, .aii and .ail files in all the destination folders. Only one destination folder has .bdb and .lfn files in them. When I look at the job stats page, only 1 of the 4 jobs ran sucessfully (the one with the .bdb and .lfn files.) Only 1 job has the job stats page completely filled out, the others only have the Database File line filled in, pointing to a .buz file in the Program Files folder. Obviously, I ony got 1 good backup out of 4. Only 1 backup has the "Restore from Backup" available. There is enough space on the destination drive.

What would cause only one job to run to completion and the other 3 to fail?

Should I delete everything in the destination folders (except the one backup that was sucessful) and hope that tonights incremental will recognize there is no full and do a full backup?

I'd really like to get this resolved ASAP.

A quick test using 3 jobs ran okay here. Please post the job parameters by cutting and pasting the command line parameters displayed on the Tools / Auto Running AISBackup form.

If possible please send a zip file containing the .buz, .bdb, .buz, .log from the database folder and the aisbackup.log and aisbackup.scr files from the AISBackup program folder. If you cannot send these files please post the job names and any extra command line parameters you have set for each job.

After the above files have been zipped you may delete the files from the backup destination of the failed jobs. If you want to do the same for the job that worked use the Manage Backup / Reset Backup option instead as the Backup Contents file will also need to be initialised.

Which version number of AISBackup are you using, the important number is the build number as indicated here: 1.10.0.224

We would like to resolve this problem ASAP too.

Barry

I responded by email.

Thanks!
Steve

The backup control files (<Jobname>.buz) files are corrupt, in fact they are empty, this is causing the stringlist exception messages, and denying access to the log because the log filename is contained within this file.

After a successful backup the <jobname>.buz files are copied to the backup media, if these files exist on the backup media and they are not zero length then they may be copied back to the backup database folder.

If the .buz files do not exists (on a previous backup?) then I am afraid
the jobs will have to be set-up again.

We have never encountered a similar problem with the .buz file before, so if it happens again we will like to try and replicate your actions leading to it.

As I said, I do not know why the .buz files got corrupt but the full logging
option may be causing a problem given the large number of files (over half a million) in the backup. AISBackup keeps a log of all files physically backed up, and this may be looked at via the View / View Sessions option, This view option is more use than the full log as the reason for the backup is given, along with a list of files 'deleted' this backup session.

From version 2.0 we are going to limit the FLMSG of the full log to 4000 per backup session. All errors, warnings and exceptions have always written to the log file regardless of the 'full log' setting, and a record of all files physically backed up is available from the menu option View / View Sessions.

On a positive point, the first tests of queuing auto-run backup jobs
when another job is already running is working in beta 2.0.

Barry

It happened again. On two backups I got the List index out of bounds (-1). Why is this happening? How do I prevent this from happening? Do I have to delete the job and recreate it again? If so, how do I do it so I don't lose the sessions?

I'd like to get to the bottom of this so it doesn't happen again. I need to be able to rely on our backups and at this point I'm not comfortable.

Please send us the job files again. The <job>.log files may have logged the error that lead to the problem. We have not encountered this problem before so any help you can give us to identify the problem is very much appreciated. If the .buz file is > zero bytes on the backup media please send also send them to us.

The job file <jobname>.buz may still be intact on the backup media, i.e. not zero bytes, if it is the following will re-instate the backup:

Manage Backup / Remove Backup, do NOT delete the backup from the backup destination.

Tools / Open Job From Backup Media, to open the <jobname>.bdb file, re-instate the backup.

Barry