I've got a problem with one of 5 servers all backing up via FTP. At the tail end apparently after uploading all the ftp files, but during the update of the summary files I'm getting the following message (and NO email)
12:10:14 PM START AISBackup started: Sunday, March 25, 2007 12:10:14 PM
JOB Full Backup TS
12:11:11 PM SSTART Complete FTP Upload on Saturday, December 30, 1899 at 12:00:00 AM
12:11:17 PM SESSEND FTP Upload Completed OK: Sunday, March 25, 2007 12:11:17 PM
12:11:17 PM EXCEPTION Exception: EConvertError: '2163882841' is not a valid integer value
12:11:17 PM EXCEPTION Component: AISFTPUpload
I just upgraded this to the latest 2.3.1 on the off chance, . . .
Anyone have *any* idea what this may be. This machine was backing up flawlessly for quite a while.
Thx in advance -- KS
Failure at end of backup Exception: EConvertError
FTP error
Did 2.3.1 fix this problem? If not I wuld like you to try the version of AISBackup that is going to be released next. However, there are still a few updates to be made before release, but if you do not mind, I would like you to try a 'test' version of AISBackup to ensure that this problem is fixed prior to release. If you agree I will send you a link to a zip file containing AISBackup.exe by e-mail.
The next version has a few updates to FTP including CRC integrity checking and supports SSL encryption (if supported by your FTP server) . For legal reasons (Export of encryption software) we may not be able to supply the SSL encryption dll's directly but they are available free of charge from various internet sources.
Barry
The next version has a few updates to FTP including CRC integrity checking and supports SSL encryption (if supported by your FTP server) . For legal reasons (Export of encryption software) we may not be able to supply the SSL encryption dll's directly but they are available free of charge from various internet sources.
Barry
2.3.1 did not fix the problem.
I'd be happy to run the latest. My guess is we've overrun an integer somewhere because of the size of something. This looks like a borland error, but I find it odd it happens at the very end of the backup.
If it blows grits, I can always roll back.
.
I'm catching flak from the client on this, but it appears the backup is actually working. -- But how do you explain that one.
THX
--KS
I'd be happy to run the latest. My guess is we've overrun an integer somewhere because of the size of something. This looks like a borland error, but I find it odd it happens at the very end of the backup.
If it blows grits, I can always roll back.
.I'm catching flak from the client on this, but it appears the backup is actually working. -- But how do you explain that one
.THX
--KS
FTP error after backup
Here is a pre-release copy of version 2.3.2 (only contains AISBackup.exe):
www.aiscl.co.uk/testversion/aisbackup.zip
** All users please register this version so that we can notify you when it is superseded **
The error may have been fixed in this version, however, extra trace messages have been added which should help identify where the error is if it persists.
Barry
www.aiscl.co.uk/testversion/aisbackup.zip
** All users please register this version so that we can notify you when it is superseded **
The error may have been fixed in this version, however, extra trace messages have been added which should help identify where the error is if it persists.
Barry
Still failing at the bitter end :)
Same Song
Second Verse . . .
10:40:01 PM RESINF 4226 Files were backed up and tested successfully
10:40:01 PM RESULT Scheduled Backup:
Completed successfully
10:40:06 PM INF Backing up Backup Contents File Database Files
10:40:08 PM STAT Time Calculating Backup: 3 Minutes 3 Seconds
10:40:08 PM STAT Time Backing up: 37 Minutes 7 Seconds
10:40:08 PM STAT Time Testing Backup: 7 Minutes 1 Second
10:40:08 PM STAT Total Time: 47 Minutes 29 Seconds
10:40:08 PM STAT Time Deleting Old Versions: 19 Minutes 16 Seconds
10:40:08 PM STAT Backed up at 410.18 MB per minute
10:40:08 PM STAT Compression Ratio: 27%
10:40:08 PM STAT Not Compressible 4463.96 MB 29% (Not included in compression ratio)
10:40:08 PM STAT Tested backup at 2,169.66 MB per minute
10:40:08 PM FTP FTP Download OK: C:\Backups\Full Backup TS\FullBackupTS.job_FTP.job.zip
10:40:08 PM STAT Time Uploading: 3 Minutes 21 Seconds
10:40:08 PM ERR Exception raised during close of backup, Stage:
10:40:08 PM EXCEPTION Exception: EConvertError: '2164112373' is not a valid integer value
10:40:08 PM EXCEPTION Component: fAquariusBackup
10:40:08 PM SESSEND Backup Session Ended: Tuesday, March 27, 2007 10:40:08 PM
Second Verse . . .
10:40:01 PM RESINF 4226 Files were backed up and tested successfully
10:40:01 PM RESULT Scheduled Backup:
Completed successfully
10:40:06 PM INF Backing up Backup Contents File Database Files
10:40:08 PM STAT Time Calculating Backup: 3 Minutes 3 Seconds
10:40:08 PM STAT Time Backing up: 37 Minutes 7 Seconds
10:40:08 PM STAT Time Testing Backup: 7 Minutes 1 Second
10:40:08 PM STAT Total Time: 47 Minutes 29 Seconds
10:40:08 PM STAT Time Deleting Old Versions: 19 Minutes 16 Seconds
10:40:08 PM STAT Backed up at 410.18 MB per minute
10:40:08 PM STAT Compression Ratio: 27%
10:40:08 PM STAT Not Compressible 4463.96 MB 29% (Not included in compression ratio)
10:40:08 PM STAT Tested backup at 2,169.66 MB per minute
10:40:08 PM FTP FTP Download OK: C:\Backups\Full Backup TS\FullBackupTS.job_FTP.job.zip
10:40:08 PM STAT Time Uploading: 3 Minutes 21 Seconds
10:40:08 PM ERR Exception raised during close of backup, Stage:
10:40:08 PM EXCEPTION Exception: EConvertError: '2164112373' is not a valid integer value
10:40:08 PM EXCEPTION Component: fAquariusBackup
10:40:08 PM SESSEND Backup Session Ended: Tuesday, March 27, 2007 10:40:08 PM
FTP Large files
This file > 2GB was causing the error, and on the test system the file was not uploaded after correcting the integer conversion error. The FTP routines used in AISBackup handle files sizes using INT64 which implies that uploads of large files should work, however I have still to find out why they are not, this may be a FTP server restriction on the server we test with (gene6).
Basically the test version here does not fail any more, but does not upload files > 2GB (so I guess it still fails - the file remains on the local PC). I could make this available to you now, or rather tomorrow (UK time) or you could wait for further investigation.
Barry
Basically the test version here does not fail any more, but does not upload files > 2GB (so I guess it still fails - the file remains on the local PC). I could make this available to you now, or rather tomorrow (UK time) or you could wait for further investigation.
Barry
FTP Files > 2GB
The server we are testing with does support files > 2GB, however AISBackup does not at the moment. It may take a while to build a proper solution, so is it possible to either exclude the outlook.pst file or (in my humble opinion) archive old data to yearly .pst files and then manually compress the live .pst file (unless of course the file represents a week of e-mail). This is not a cop-out by us but a work-around until the problem is fixed properly.
You probably already know this: An outlook file will need to be backed up when 'touched' by Outlook, even if no data is changed when a .pst file is opened it will get backed up again. Therefore, even if you do archive to separate .pst files I would recommend keeping them closed unless you (or you colleague) are looking for old data.
I guess this backup is over a very fast network?
Barry
You probably already know this: An outlook file will need to be backed up when 'touched' by Outlook, even if no data is changed when a .pst file is opened it will get backed up again. Therefore, even if you do archive to separate .pst files I would recommend keeping them closed unless you (or you colleague) are looking for old data.
I guess this backup is over a very fast network?
Barry
Wait . . . The 2G file is up ...
Barry,
I'm working the @#!$% pst issue. As I said, another issue altogther, ridiculous mailbox.
OTOH the zip file is uploaded. The problem occurs during the update of the summary files at the end. This looks like an overrun while walking thru each uploaded file at the end.
I'll double check, but I'm fairly certian all the zipfiles are up, the .xml / status file is the upload problem. It's like it pukes trying to build the summary and never uploads those last couple of small files.
ks
I'm working the @#!$% pst issue. As I said, another issue altogther, ridiculous mailbox.
OTOH the zip file is uploaded. The problem occurs during the update of the summary files at the end. This looks like an overrun while walking thru each uploaded file at the end.
I'll double check, but I'm fairly certian all the zipfiles are up, the .xml / status file is the upload problem. It's like it pukes trying to build the summary and never uploads those last couple of small files.
ks
FTP big files
I can confirm that AISBackup did not upload files > 2GB because it saw them with a negative file size. However, they may be on the FTP server with zero size.
AISBackup has been updated to allow FTP of files up to 4GB, if there is a requirement for more than this then there will have to be another update.
I will let you know the download link after more tests have been run.
Barry
AISBackup has been updated to allow FTP of files up to 4GB, if there is a requirement for more than this then there will have to be another update.
I will let you know the download link after more tests have been run.
Barry
FTP error
Release candidate 2.3.2 has been uploaded:
http://www.aiscl.co.uk/aisbackup_beta.htm
This version allows backup file of up to 4GB to be created in FTP backups.
Please let us know if this fixes the problem with your FTP job.
Barry
http://www.aiscl.co.uk/aisbackup_beta.htm
This version allows backup file of up to 4GB to be created in FTP backups.
Please let us know if this fixes the problem with your FTP job.
Barry