Restore can't find .lfn file

[jstrong]

I'm running version 1.9.1.208 on XP SP2.

When trying to carry out a test restore this morning from new backup, AISBackup reported an error "can't find file xxxxx_144.lfn". When I tried to find it, I discovered that all files were named xxxxx.bdb_144.lfn.

I then selected that file. The restore took a long time to complete, reported a success, but the file was truncated / corrupted in some way (an mp3 file - that stopped half way through).

Any help / guidance would be much appreciated!

Thanks

Jim

[jstrong]

I should have added that I am backing up across a network. I've just tried a test on a slightly older, different backup set, but selected the same file to restore. This one found the backup file it was looking for (a zip file in this case - not sure why the newer one has .lfn as the extension?), but the file is still truncated - at 3mb. It looks like two different problems, therefore?

The time taken to restore was of a similar length to the newer backup reported above.

Thanks

Jim

[jstrong]

Sorry for multiple posts, but with regard to the truncation problem, I have discovered that if I restore the file to a local drive and then copy it across the network, the file is fine.

Jim

[Barry]

Segment details about large files (by default over 100MB) are held in a file called <jobname>.bdb.lfn This file should be in both the AISBackup database folder and on the actual backup destination.

Do both jobs restore locally okay? Is the file intact when restored locally?

Please send us the job files via the Help / Bug Report option.

Is there anti-virus software running on the networked destination drive (may be slwing down the restore) and is the destination pre-mapped to a drive letter?

Barry

[jstrong]

Yup - the <jobnam>.bdb.lfn files is in both the AISBackup database folder and on the actual backup destination.

Yes - they restore OK locally - file is intact

No anti-virus on the destination drive, but although this is on an Apple Mac I have no problems in file copying etc. from and to the Mac/PCs.

Yes, the destination is pre-mapped as drive Z:

One of the job files is over 10mb - if I email the newer, smaller one, could you let me know if you still need the old big one and I'll get it uploaded to a web site for you to pick up.

Many thanks

Jim

[/code]

[Barry]

It may be that restore to a MAC does not work with large files. Please try increasing the 'huge file size' to > the size off .mp3 and just backup this file and restore directly to the MAC.

Huge files are restored in segments, the file is pre-allocated before the restore because the segments need not be in file order. This 'seeking' to different parts of the file may be causing the problem - no MAC experts here - just a little knowledge. Are you using the MAC 'DAVE' interface? That is the only TCP/IP MAC interface we have access to.

Barry

[jstrong]

Huge file size is already 100mb and the mp3 is around 5mb.

I am on MAC OSX and that uses Windows File Sharing. As far as I know, that is basically TCP/IP and samba (I forget what the latter is, but can find out in need). I regularly transfer large files to and from the PCs / Mac.

However, I have just successfully restored the same file to another PC on the network, so it does point to the network protocols with the Mac, which I imagine you might well say is my problem to sort out? Fair enough!

I should mention that AISBackup is brilliant - because it cuts the backup into small zip files - in circumventing a 2 mb restriction that other backup programs (e.g. Retrospect costing several hundred pounds) have when backing up across a network! I can't use Retrospect because of this.

Finally, though, I am left with this .lfn file recognition problem which I don't think is a Mac-related item.

Thanks a lot

Jim

[jstrong]

Just to say that I understand that the file truncation problem is probably down to networking across to the Mac and for me to solve, but are you able to help me with the original problem of AISBackup looking for files called "xxx_144.lfn" on restore, whereas the files are actually named xxx.bdb_144.lfn?

Thanks a lot

Jim

[Barry]

Basically I think AISBackup is getting upset because the backup destination ‘zip’ files have names ending with the same suffix as the AISBackup database files. The backup destination usually defaults to <jobname>.zip but we recommend that the .zip ma be changed to avoid anti-virus software checking al backup files, which slows down the backup. What we did not do was stop AISBackup database extensions from been used, e.g. .bdb.lfn. If you are able to rename the .bdb.lfn the Manage Backup / Validate Backup option.

I will create a backup using the same backup destination as yourself to properly understand the consequences, and maybe provide a fix. At the very least we will improve the destination filename validation routine.

Barry

[jstrong]

Thanks Barry - I'll have a go at renaming using the Manage Backup / Validate Backup option and see what happens. (Is that what you meant? The sentence looks as thought there is something missing).

Jim

[Barry]

You may not be the only one who creates a backup destination filename with .xxx.yyy extension. Instead of renaming the files we will fix the problem from this end and let you know when we have uploaded the AISBackup.

Barry

[jstrong]

OK - thanks a lot, as ever

Jim