Backup Exec // B2D media used for Exchange 2007 Information Store associated to scratch media
Hello, I am new to Symantec BEWS and I have just created a new Disk-to-Disk-to-Tape backup job copying predefined policy "Duplicate Backup Sets 00001". BE Media Server is running Windows Server 2003 R2 SP2 while the Exchange Server is running Windows Server 2008 SP1 with MS Exchange Agent. Target device for the Disk-to-Disk job is a newly created Backup-to-Disk folder, target media set is a newly created media set with 1 week OPP and 8-hour AP. Last night the Disk-to-Disk backup job ran the first time and completed successfully without errors. This morning I went through the device and media information section under job history. This section showed "B2D000006", "IMG000004" and "IMG000005" as used media, but how comes that "B2D000006" media belongs to pre-defined Scratch Media set while both "IMG000004" and "IMG000005" belong to the newly created media set according to Template properties ? I know that GRT-enabled backup jobs result in IMG folders being created during job execution, but how comes that media created during the same backup job is associated to different media sets ? Furthermore how comes that used capacity for that media is not shown under Devices -> Backup-to-Disk folders -> My Backup-to-Disk folder while used capacity for other media under different Backup-to-Disk folders used for normal file backup jobs is displayed ? Any help is much appreciated. Have a great day. Regards, Massimiliano
Exchange 2007 non-GRT Backup is 22x times faster than GRT backup
I'm using the following: Backup Exec 12.5for Windows with Service Pack 3installed (incl the latest hotfixes) Windows Server 2008 Service Pack 2 All servers have Gbit NICs connected to Gigabit swithes Exchange 2007Service Pack 2+Rollup 1 The Exchange Information Store is about 10GBin size An Exchange GRTbackup has an averagethroughput of 82MB/min (and thus takes about 2hours to complete). An Exchange non-GRTbackup has an average throughput of 1817MB/min (and takes only 6minutes to complete). Ifind theperformance of the GRTbackup (which is 22x times slower) unacceptable. While investigating the cause, Inoticed the following behaviour of Backup Exec: A snapshot is created using the Microsoft Software Shadow Copy provider 1.0 (Version 1.0.0.7). The data in the snapshot is accessed on the Exchange server by the BEREMOTE.EXEprocess. The BEREMOTE.EXEprocess on the Exchange server sents the data over a TCPconnection to the BEREMOTE.EXEprocess on the Backup server The data is sent in chunks of 64KB which takes about 1.2milliseconds The client then has to wait for about 40milliseconds for a response from the server, before it can sent the next chunk of 64KB. Since the ethernet protocol has an MTUof 1500bytes, it has to sent the data in several smaller packages (44x 1460data bytes) The 44 packages are all sent within 1.2ms, and then it takes 40milliseconds (and sometimes even more) before it can sent the next chunk. The Backup Server writes the data to files in an IMGxxxxxxx folder as a subfolder in the Backup-to-disk location. The files in the IMGxxxxxxx folderare a 1:1 replica of the snapshot data. The slowness is due to a 'bug' in the BEREMOTE.EXE Iverified this by accessing the above Snapshot using the MKLINK.EXEcommand (see http://blogs.msdn.com/adioltean/archive/2008/02/28/a-simple-way-to-access-shadow-copies-in-vista.aspxfor details) The copy of the same data over the network to the same harddisk location using Windows built-in COPY (or XCOPY) command took proceeded at a rate of about 250Mbps a second over the SMB protocol). When performing a NON-GRTbackup, the client does not have to wait 40milliseconds, but can simply continue to sent the data in one large data-stream and the server seems to handle this correctly. For the NON-GRTbackup the 'TCP Receive Window' always remains 64240bytes and therefore the client keeps sending data. For the GRT-enabled backup: the 'TCPReceive Window' decreases for every TCP-ACKsent, until it's too small, and therefore the client has to stop. After the described timeout of +/- 40milliseconds, the server sends a 'TCPWindowUpdate' to the client (a reset of the TCPReceive Window to 64240bytes) after which the client immediately start sending its data to the client. The actualthroughput is not limitedby the network, but is actually limited by the design of the GRT-backup. It therefore suffers from the following disadvantages: The network is kept busy for an extended period, and therefore the risk of job failure due to network interruptions increases accordingly. The remote agent on the client is kept busy for an extended period The snapshot is kept online for an extended period, putting an additional load on the server +additional disk space on a heavily used server. How comes the client may not keep sending it's data (or why is the Window Size decreased for GRTbackup, while it's not decreased for non-GRT backup)? Is Backup Exec analyzing the contents of the Information Store on-the-fly while it's receiving the data? It seems to me that it only processes the data once that all data has been transferred, because only after all data has finished, it creates an IMGxxxxxx\vdb_date_time subfolder with some additional data in it. However I'm not sure about this. If Backup Exec is not processing the contents on-the-fly: why is the transfer taking so long? If Backup Exec does process the data on-the fly: wouldn't it be better to process the contents AFTERalldata has been transferred? This design would solve the above disadvantages, and it would make more sense if the job details would show: 6minutes required to transfer +114 minutes required to extract individual messages. In case some technician is interested: IhaveNetwork Traces (wireshark)of the above behaviour, in case it cannot be reproduced. Kind regards, br_nar
Backup duplicate to tape
Hi, Wehave installed BE 12.5 in a new installed server. Nowwe're doing Exchange 2007 B2D using CPS, and schedule for full backup to run in scheduled time. B2D runs fine, but when another job runs to duplicate it to tape, it goes all OK until around 2GB before finishing. It stucks there for around 2 hrs, than it continues. Now it verifies the backup, it again stuck a bit before finishing, and only changes state between QUEUED, and Loading Tape. We're using HPLTO4 brand new Tape Drive. Thank you for any help.
EXCHANGE RESTORATION
Hi, Environment : Backup Exec 2010 R3 ( win2k3 32 bits Enterprise Edition ) Exchange 2003 ( win2k3 32 bits Enterprise Edition ) When we going to perform restoration of user mailbox, Old Mails of user are also showing for restoration which user have downloaded in local PST before the Backup was Done. Old mails are showing in almost all users mailboxes . Kindly refer the attached screenshot. Regards, VINAYYBackup Exec 2010R2 agents upgrade
Hi All, I've just successfully install BE 2010 R2, i wonder if i should upgrade the agents in all o my systems (Exchange, SHarePoint, SQL Server or Domain Controllers) for it to work properly ? from the what's new the R2 only affecting SharePoint server 2010, while mine is 2007 do i still have to upgrade it ?