Product: Vtrak 15100

Platform: Independent

Backup Exec v9.1.4691 + VT M500i + 15 disk RAID 0 for 5.45 TB NTFS volume (Win2003/SP1 GPT Disk)     = Pass

Backup Exec v10.0.5484 + VT 15200 + 6 disk RAID 0/5/10 – 512 byte sector (Win2003 /no SP MBR Disk)      = Pass

Backup Exec v10.0.5484 + VT 15200 + 6 disk RAID 0/5/10 – 1024 byte sector (Win2003 /no SP MBR Disk)    = Pass

Backup Exec v10.0.5484 + VT 15200 + 6 disk RAID 0/5/10 –

2048 byte sector (Win2003 /no SP MBR Disk)    = Fail

Backup Exec v10.0.5484 + VT 15200 + 6 disk RAID 0/5/10 –

4096 byte sector (Win2003 /no SP MBR Disk)    = Fail

 

There are two issues that I saw:

1.

If Backup Exec is install onto the disk array that is using >512 byte sectors, then the installation will abort and in the log file you will see this entry:

05-04-2005,10:29:00 :  Installing BE database.

05-04-2005,10:29:00 : Executing Attach_BEDB.

05-04-2005,10:29:10 : The SQL server SYS51\BKUPEXEC with service name of MSSQL$BKUPEXEC has been started

05-04-2005,10:29:10 : DRIVER={SQL Server};SERVER=SYS51\BKUPEXEC;Trusted_Connection=Yes

05-04-2005,10:29:11 : Connected to SQL Server.

>>>05-04-2005,10:29:11 : Failed to get data for SQL statement: select filename from master..sysdatabases where name='BEDB'

05-04-2005,10:29:11 : Attaching BEDB to SQL Server.

05-04-2005,10:29:11 : EXEC spattachdb 'BEDB',@filename1 = N'F:\Exec Installed\Data\BEDBDat.mdf', @filename2 = N'F:\Exec Installed\Data\BEDBLog.ldf'

>>>05-04-2005,10:29:13 : ERROR: Cannot use file 'F:\Exec Installed\Data\BEDB_Log.ldf' because it was originally formatted with sector size 512 and is now on a device with sector size 1024.

Device activation error. The physical file name 'F:\Exec Installed\Data\BEDB_Log.ldf' may be incorrect.

Cannot create file 'F:\Exec Installed\Data\BEDB_log.LDF' because it already exists.

Could not open new database 'BEDB'. CREATE DATABASE is aborted.

sql:EXEC spattachdb 'BEDB',@filename1 = N'F:\Exec Installed\Data\BEDBDat.mdf', @filename2 = N'F:\Exec Installed\Data\BEDBLog.ldf'

2.

For the two test failures listed above, the behavior was the same.    After creating the job and executing, the job status would jump from ‘initializing’ to ‘queued’.    When I checked the Windows Application log, I saw many error messages while the jobs were attempting to run:

5/4/2005 11:05:57 AM Backup Exec Error - An error occurred while processing a B2D command.

Changer: Couldn't ReadFMTables/RecoverBKF (e:\Backup-to-Disk Folder 1\B2D000001.bkf).  Error=87

5/4/2005 11:05:57 AM Backup Exec Error - An error occurred while processing a B2D command.

Drive: ReadFMTable() SetFilePointer failed (e:\Backup-to-Disk Folder 1\B2D000001.bkf).  Error=87

 

For Item #1, the Backup Exec must ALWAYS be installed to a disk that is based on 512 byte sectors.

For Item #2, the Backup Exec could use media disks that are based on 1KB sector size (maximum capacity is 4TB) but 2KB and 4KB are not supported by the application.

 

For all issues, Service Pack 1 can be applied where GPT disks can resolve all capacity and compatibility issues.

 

Additional Information:

I believe this is nothing more than a volume size issue.

 

When we used to create >2TB disk arrays, we stated that the host needed to either support 64-bit LBAs (for 512 byte sectors) or variable disk sector sizes (1024, 2048 bytes).    

 

Traditionally, Windows NT/2000/2003 did not support 64-bit LBA addressing with 32-bit operating systems.    When Microsoft developed the 64-bit operating systems for Extended 64 and Itanium architectures they did take this into consideration and implemented GUID Partition Tables (GPT opposed to MBR disk) which addressed the large LBA count.

 

Promise pushed users to use >512 byte sectors when creating disk arrays >2TB.   This is okay for non-data base or non-high availability applications.    

However, most of the dbase or HA apps require full control over the HW being used down to the low-level byte access (don’t get me wrong, these applications can be manipulated to use >512 byte sectors – but it generally takes a highly paid contractor or system admin to implement).

 

Until recently, Microsoft announced GPT support for Windows 2003 Server with the release of Service Pack 1 on 32-bit architectures.   This has been verified in the SQA Lab already and works extremely well with 512 byte sector disks (around 7.2 TB for a single NTFS volume).

 

The Backup Exec application is based on a scaled down SQL database which requires 512 byte sectors.    Disk arrays that are created with 1024 or greater bytes may simply fail after the data that has been verified by BE but before any data has been written to the backup storage device that is using >512byte disk sectors.    (This is why I would like to see the BE logs to confirm my theory).    

 

In my testing I stick to as many default settings and standardized practices as possible.

 

I am using Windows 2003 Server, EE with Service Pack 1

 

Source:

Promise FastTrak SX4100 with 4-disk RAID 0/128KB SBS/WriteBack Cache = 320GB storage

                252GB of data (140GB uncompressed)

                623,910 files (561,960 are uncompressed)

                13,650 folders

Target:

Promise VTrak M500i with 15-disk RAID 0/64KB SBS/WriteBack Cache/512 byte disk sectors = 5.45TB storage

                GUID Partition Table and NTFS volume

               

               

Please ask customers to:

1.

      Apply SP1 to their host machines

2.

      Restore all RAID System default settings (15100 or 15200)

3.

      Define 1 large disk array using 512 byte disk sector size

4.

      Map the storage to the applicable host port

5.

      Upgrade the disk under the LVM to GPT disk from MBR disk (be sure that they do not upgrade from Basic to Dynamic disk)

6.

      Create the NTFS partition

7.

      Setup the Media disk under Backup Exec

8.

      Execute a backup