TeraByte Unlimited

I have a tbos script that executes (under bootitBM) 6 image.exe backups to a common (scsi) NTFS backup drive.
All 6 backups indicated successful completion in the IFD.log file

After a reboot, Windows indicated that the backup drive was not usable, and needed to be formatted.
I booted to TBOS and tried to mount the backup drive. TBOS indicated that the drive was not usable.
BOOTITBM -partition work- seemed to indicate that the partition was there, and was apparently usable.
I Booted back to Windows, Backup partition still not usable, and needs to be formatted. I did NOT format.
Ran checkdsf /f on the backup drive, just to see what would happen.
Chkdsk indicated that the NTFS primary MBR was corrupt, and that the secondary MBR would be validated.
After many index errors, and index rebuilds, the drive was apparently back in perfect working order.
5 of the backups created the correct .TBI backup files. the 6th backup did not create any backup files, or chkdsk removed them.

I ran my script again, this time all 6 backups were correctly created, and the backup drive was operable after reboot.

Question: The log indicated successful completion ( and I assume validation), yet something went wrong somewhere. Should I be running with an increased diagnostic level to help spot the error if it happens again? I've use this script for years, every week to backup my partitions. This was the first error of any kind, but this was the first backup execution since installing 2.86.

I should state that my script ends with a" bootndos /None " that takes me back to BOOTITBM.

You need to disable fast boot with any of the Win8 installs also, you can't
hibernate then boot a boot disk and backup either.

FWIW, I think you mean tbosdt, you can't mount a NTFS partition from TBOS,
only from TBOSDT. Also note that you can't mount a partition in TBOSDT,
then launch something that modifies the mounted partition. Also, if you
have drive caching enabled in TBOSDT then you shouldn't have any other
partition mounted on that same drive, instead you should disable any drive
caching that you have enabled prior to launching something that will modify
the drive.


"tas3086" wrote in message news:[email protected]...

I have a tbos script that executes (under bootitBM) 6 image.exe backups to a
common (scsi) NTFS backup drive.
All 6 backups indicated successful completion in the IFD.log file

After a reboot, Windows indicated that the backup drive was not usable, and
needed to be formatted.
I booted to TBOS and tried to mount the backup drive. TBOS indicated that
the drive was not usable.
BOOTITBM -partition work- seemed to indicate that the partition was there,
and was apparently usable.
I Booted back to Windows, Backup partition still not usable, and needs to be
formatted. I did NOT format.
Ran checkdsf /f on the backup drive, just to see what would happen.
Chkdsk indicated that the NTFS primary MBR was corrupt, and that the
secondary MBR would be validated.
After many index errors, and index rebuilds, the drive was apparently back
in perfect working order.
5 of the backups created the correct .TBI backup files. the 6th backup did
not create any backup files, or chkdsk removed them.

I ran my script again, this time all 6 backups were correctly created, and
the backup drive was operable after reboot.

Question: The log indicated successful completion ( and I assume
validation), yet something went wrong somewhere. Should I be running with
an increased diagnostic level to help spot the error if it happens again?
I've use this script for years, every week to backup my partitions. This
was the first error of any kind, but this was the first backup execution
since installing 2.86.

I should state that my script ends with a" bootndos /None " that takes me
back to BOOTITBM.

- Using Windows 7 - No fast boot
- Powercfg has hibernate disabled, no hibernate files on any partitions.
- Tbosdt was only used to mount the partition to see if I could see the files that IMAGE.exe just created.
- Drive caching is whatever the default is, and the corrupt backup drive is a single partition.

Like I said, I have used this script for years (every week) and never had a problem. I only bring it up because this was my first use of version 2.86 code. It is interesting that the IFD.log says a normal completion, but the backup files are not existing, and the disk (master NTFS MBR) is corrupted.

Are there any additional diagnostics that I could add that would help if the problem were to happen again?
Or should I add a delay between the end of image.exe execution and the start of bootndos , to allow additional flushing time ?
Or any chance that your new iocf (small cache I/O) option might be involved?

"tas3086" wrote in message news:[email protected]...

- Using Windows 7 - No fast boot
- Powercfg has hibernate disabled, no hibernate files on any partitions.
- Tbosdt was only used to mount the partition to see if I could see the
files that IMAGE.exe just created.
- Drive caching is whatever the default is, and the corrupt backup drive is
a single partition.

Like I said, I have used this script for years (every week) and never had a
problem. I only bring it up because this was my first use of version 2.86
code. It is interesting that the IFD.log says a normal completion, but the
backup files are not existing, and the disk (master NTFS MBR) is corrupted.

>> If it was able to mount and finish then it was fine at that point.
>> Issues that occur the way it did (after booting windows) is typical if
>> hibernation type issues. But as mentioned, you have to be sure you
>> don't have it mounted in tbosdt while doing the backup as well.

Are there any additional diagnostics that I could add that would help if the
problem were to happen again?

>No.

Or should I add a delay between the end of image.exe execution and the start
of bootndos , to allow additional flushing time ?

>No, not needed. But you do have to ensure you don't have drive caching
>enabled in the script while launching anything external.

Or any chance that your new iocf (small cache I/O) option might be
involved?

> No.

Thanks. Hopefully it will not happen again.