Quantcast
Channel: Symantec Connect - Backup and Recovery - Discussions
Viewing all 7183 articles
Browse latest View live

Problems with BUE and VMWare Backups

$
0
0
I need a solution

I have been told that I will have a few project shortly to upgrade some of our clients to BUE2014. Awesome I say, time to play with it in my lab.
I download and install the trial, set it up no issues. Go to back up DC01 on ESX01 via vCenter. Fine, works great. Add DC02 on ESX02 to the same job, also via same vCenter. Can't quiesce the snapshot, backup fails.

First step was to remove and reinstall agent, no joy. Next I removed the VM from inventory, and even removed the ESX host from vCenter, still won't backup. Out of desperation, I re-initialised the DB on my vCenter appliance. Re added everything, and nope, still no love.

I removed everything from that ESX box, and re installed ESX. Ran up a brand new VM (Server 2008r2) installed VMWare tools and BUE Agent. Same error.
When I snapshot the machine directly from vSphere, while logged on as the service account used for the backups, no problems. Can create a quiesced snapshot and remove it without an issue.

Now, is this some kind of limitation with the Trial period, or is there some other issue going on?

I haven't tried backing up directly from the ESX host as of yet, but that kind of defeats the purpose


Backup Exec 2014 AVVI GRT Catalog/Verify incredibly slow...

$
0
0
I need a solution

Hi,

I am posting this here and logging a case for it with Symantec in the hope that someone has a fix...

I am backing up a lot of VM's on VMware using NBD (Soon to be SAN Transport) with a target of a deduplication store located on an EMC VNX SAN attached via fibre.

Most backups are of fairly small VM's with no GRT option selected and these are fine...

I have two file servers which have 800GB and 1.2TB of data stored as VMDK's, for these servers I require GRT so I have enabled only Backup Exec GRT...

The backup for these two servers takes approximately 10 hours total... (2900 and 3200MB a minute throughput according to job log)

Then the catalog process begins and eventually I have to cancel it because it takes such a long time... In 7 hours it had cataloged approximately 200GB of data with a job rate of around 750MB a minute!!! What is really frustrating here is that the server does not appear to be doing anything... IO to the SAN as measured by EMC PowerPath is minimal...

Once I cancelled this the job then began a verify...

Somehow the verify takes 16 hours at 1765 MB a minute (So it is actually taking longer to verify the backed up data than it does to actually back it up?)...

Am I missing something here?

Basically a GRT backup of my file servers at this moment in time is pointless because cataloging the data is so horrendously slow... I saw BE 2012 had similar issues with large amounts of files on AVVI jobs but thought this had been resolved...

More detail:

Dell R710 with 2 x Quad Core Intel E5530 with 16GB of RAM running Backup Exec 2014 with all updates installed on Windows Server 2008 R2 Standard with all updates installed. Microsoft Forefront 2010 AV installed with Excluded files and locations set for the entire C:\Program Files\Symantec folder and the entire drive holding the deduplication store

How to disable automatic push install

$
0
0
I need a solution

Backup Exec 2014. Noticed there are lots of log-files in C:\ProgramData\Symantec\Backup Exec\PushLogs directory. Currently I really don't want Backup Exec to do automatic push installs (which fail). I am in a process of fixing server environment manually and this complicates things.

Don't find anywhere setting to disable this. Maybe it needs registry change but not sure which one. Maybe:

HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\Agents\Auto Discovery Enabled ?

 

Backup fails...

$
0
0
I need a solution

Hello 

 

I have a problem with backupexec 2010

The backup keeps failing with:

 

V-79-57344-65247 - A failure occurred reading an object.

WARNING: "System?State\System Files\System Files" is a corrupt file. This file cannot verify.

 

 

So I run SGMon  and created only System state backup:

 

And found this error:

BEREMOTE: [07.23.14 08:33:30] [0000]     [17456] 07/23/14 08:33:30 [fsys\brfs]          - brUtil::OpenActiveObject Error: 0xE0008485 Could not open the object amd64_5000364743d6848b783ac58e56089326_31bf3856ad364e35_6.1.7601.18429_none_5cf0b22b54897387.manifest C:\Windows\winsxs\Manifests\amd64_5000364743d6848b783ac58e56089326_31bf3856ad364e35_6.1.7601.18429_none_5cf0b22b54897387.manifest
BEREMOTE: [07.23.14 08:33:30] [0000]     [17456] 07/23/14 08:33:30 [fsys\shadow]        - Status FS_IN_USE_ERROR (0xE0008485) for Component System Files in SHADOW::ReadComponent
BEREMOTE: [07.23.14 08:33:30] [0000]     [17456] 07/23/14 08:33:30 [fsys\systemstate]   -   AD:Status FS_READING_OBJECT_FAILURE (0xE000FEDF) calling FS_ReadObj in SystemState::ReadObj:259
BEREMOTE: [07.23.14 08:33:30] [0000]     [17456] 07/23/14 08:33:30 [fsys\shadow]        - Informational: Closing Component 'System Files'
BEREMOTE: [07.23.14 08:33:30] [0000]     [17456] 07/23/14 08:33:30 [fsys\shadow]        - Informational: calling IVssBackupComponents::SetBackupSucceeded with status 'FS_READING_OBJECT_FAILURE (0xE000FEDF)' for Component 'System Files' in SHADOW::CloseComponent

 

But there is no such file in that directory.

 

So I run it again with folowing error:

 

BEREMOTE: [07.23.14 09:33:24] [0000]     07/23/14 09:33:24 [fsys\brfs]          - brUtil::OpenActiveObject Error: 0xE0008485 Could not open the object amd64_c775423156e673f5cb6559da47b277b4_31bf3856ad364e35_6.1.7601.22639_none_c84f5adb50c6c719.manifest C:\Windows\winsxs\Manifests\amd64_c775423156e673f5cb6559da47b277b4_31bf3856ad364e35_6.1.7601.22639_none_c84f5adb50c6c719.manifest
BEREMOTE: [07.23.14 09:33:24] [0000]     07/23/14 09:33:24 [fsys\shadow]        - Status FS_IN_USE_ERROR (0xE0008485) for Component System Files in SHADOW::ReadComponent
BEREMOTE: [07.23.14 09:33:24] [0000]     07/23/14 09:33:24 [fsys\systemstate]   -   AD:Status FS_READING_OBJECT_FAILURE (0xE000FEDF) calling FS_ReadObj in SystemState::ReadObj:259
BEREMOTE: [07.23.14 09:33:24] [0000]     07/23/14 09:33:24 [fsys\shadow]        - Informational: Closing Component 'System Files'
BEREMOTE: [07.23.14 09:33:24] [0000]     07/23/14 09:33:24 [fsys\shadow]        - Informational: calling IVssBackupComponents::SetBackupSucceeded with status 'FS_READING_OBJECT_FAILURE (0xE000FEDF)' for Component 'System Files' in SHADOW::CloseComponent
 

 

So this time a different file.

But again tehre is no such file in C:\Windows\winsxs\Manifests\ directory.

So Im getting file in use error on file that isnt there in the first place ?

Problem beim Wiederherstellen eins Public Folders per GRT

$
0
0
I need a solution

Hi,

 

es läuft BEXR 2010 R3 inkl. alle Updates. Wir haben per GRT die PublIc Folder eines SBS 2003 Exchange gesichert. Wir versuchen nun, einige Elemente aus der Sicherung per Exchange Umleitung auf einem Exchange 2010 SP3 wiederherzustellen. Für einige Elemente klappt es auch, aber leider bricht die Wiederherstellung regelmäßig mit diesem Fehler ab:

 

Auftrag beendet am Mittwoch, 23. Juli 2014 um 11:12:55
Abschlussstatus: Fehlgeschlagen
Endgültiger Fehler: 0xe00002fd - Eine oder mehrere Eigenschaften für für eine oder mehr Nachrichten oder Ordner können nicht wiederhergestellt werden. Überprüfen Sie die Ressourcen-Identifikationsdaten für den Auftrag und führen Sie ihn dann erneut aus.

Endgültige Fehlerkategorie: Ressourcenfehler

Zusätzliche Informationen zu diesem Fehler finden Sie unter der Verknüpfung V-79-57344-765

 

Innerhalb des Logs ist noch folgendes zu lesen

 

Wiederherstellen- \\SMR-EXCHANGE01\Microsoft Information Store\Mailbox Database 1332292506 SMR-EXCHANGE01V-79-57344-765 - Eine oder mehrere Eigenschaften für Anfrage  Reisen können nicht festgelegt werden.
V-79-57344-765 - Eine oder mehrere Eigenschaften für Bitte um Rückruf können nicht festgelegt werden.
V-79-57344-765 - Eine oder mehrere Eigenschaften für Anfrage zu Reisen können nicht festgelegt werden.

 

 

Im Wiederherstellungsauftrag sind die Logindaten des Domänenadmins angegeben. Ein Klick auf Alles testen" bringt keine Fehlermeldung.

 

Was kann die Ursache für dieses Verhalten sein?

 

Problem with backup Cluster Hyper-V 2012

$
0
0
I need a solution

Hi,

I have a problem with the backup of virtual machines on Hyper-V 2012 In cluster.

Server "backup exec 2012 SP4" is on Windows 2008 R2.

Agent is on two hosts Windows Server 2012 - this servers are in cluster hyper-v.

I have also hyper-v cluster on 2008R2, but here make backup ok.

In backupexec server i dont see any hyper-v machine, but test credentials is correct.

I trying to make a backup of virtual machines in the cluster 2012 Hyper-V, but I have Error on the side of the agent in system events:

Service error Volume Shadow Copy: Unexpected error during testing IVssWriterCallback interface. hr = 0x80070005, Access is denied.

 

This is log for agants in host:

Win8DedupVolume::Initialize. Failed to get Volume Letter. Error code = 8004100E

NTFS_SetupVolumeFlags:Failed to Initalized WMI for win8 with 8004100e.

c:\ClusterStorage\SWS1\' CSVFS: {COMPRESSION} {SUPPORTS_ATTRIBUTES} {DATES} {ACCESS DATES} {DATA_SECURITY} {UNICODE} {CASE_PRESERVING} f=0x03111479 x=0x06000000 volflags=0x03C5005E

 dsserver.cpp (379):
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [dsss]               | DS session handle: 0000000007BE0910(00000000757F8D60) opened.
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [ndmp\dsss]          + ndmp_dsserver.cpp (224):
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [ndmp\dsss]          | DS_OpenEnumRoot
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [ndmp\dsss]          + ndmp_dsserver.cpp (236):
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [ndmp\dsss]          | Resolving device for open enum
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\shared]        - FS_ResolveDevName: [\\cluster56]
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\mb2]           - MB2-Resolve returned 1
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\notes2]        - Notes Agent:CLNFileSystem::ResolveDeviceName
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\sql2]          - NOT SQL Device Name: \\cluster56
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [beutil]             - ApplyRegExp(): Invalid input (\\cluster56). Parsing Failed.
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [beutil]             - GoodEvName(): Invalid EV device (\\cluster56).
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [beutil]             - ApplyRegExp(): Invalid input (\\cluster56). Parsing Failed.
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [beutil]             - GoodEvName(): Invalid EV device (\\cluster56).
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [beutil]             - Input Error (e000fe23) for Type: (43)
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\ev]            - EVM_ResolveDeviceName: Function Enter
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [beutil]             - ApplyRegExp(): Invalid pattern. InputString (\\cluster56). RegEx (EVM::\\\\{.*?}\\{.*}).
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\ev]            - EVM_ResolveDeviceName: Invalid device name (\\cluster56). Parsing Failed.
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\ev]            - EVM_ResolveDeviceName: Function Exit
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\ntfs]          - Not valid device name : \\cluster56
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [ndmp\dsss]          + ndmp_dsserver.cpp (250):
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [ndmp\dsss]          | Resolved succeeded: os ID = 0xe; device ID = 0x2
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [dsss]               + dsserver.cpp (511):
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [dsss]               | Checking for open enumerations on session 0000000007BE0910(00000000757F8D60)
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [dsss]               + dsserver.cpp (540):
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [dsss]               | No open enumerations found
BEREMOTE: [07-08-14 09:37:48] [3904]     2014-07-08T09:37:48.241 [fsys\shared]        - FS_BlowOutMachine: entered -->\\cluster56<--

ADD Servers w/ Trust Established Succeeds but won't show up

$
0
0
I need a solution

 

Hello guys,

 

I had to recreate our Backup Exec 2012 backup schedule due to someone making some mistakes.

I deleted all but the underlying server it was operating on (my understanding is you can't remove the server it resides on) and when I went to re-Add Server one in particular it is 'Successful' and I check marked the Establish Trust when adding.

The server never populates on the list.  I added 2-3 other ones the exact same way and they show up and are also 'Successful'.

 

Anyone know why this would happen?  Why this one server would not populate?

 

If I add it as a File Server it doesn't not work properly since it is a PDC/DNS/Exchange Server

Need Advice Regarding Getting Back to BE

$
0
0
I need a solution

I have been using Microsofts DPM 2007 on a W2K3 32-bit server since 2007.  Used BE for many years before that including netware Agents.  Still have Version 11 somewhere.

It is my intention to replace DPM 2007 with a W2K8 R2 64-Bit Server and BE 2014, but need advice on what I will need.  I currently using Quantum LTO 4 Tape weekly (for offsite) and two HP MSA 20 Smart Array (SATA disks) Daily Full as well as Incremental backups.

I am currently backing up shares on W2K8 64-bit vmware servers running on free ESXi 5.0 as well as a W2K3 32-bit SQL 2005 Server.  I have just ordered a replacement for the SQL, it will be a physical HP DL360p Gen 8 with either SQL 2012 0r 2014 Standard SQL.

So what do I need to backup:

  1. W2k8 64-Bit VMWare File Server
  2. W2k8 64-Bit VMWare App server
  3. W2K12 DC (I have not been backing this up and am not sure I need to, as it is in a larger domain and is not primary DC)
  4. W2K8 64-bit physical SQL server (New Purchase as above)

I also have the following which I am currently not backing up, and may not need to:

  1. W2K8 64-Bit VMWare WSUS server
  2. W2K8 64-bit VMWare Print Server
  3. W2k8 32-Bit Physical Terminal Server

I am making this switch back to BE as the other sites in my domain all use BE and I am contemplating retirement.

What version of BE 2014 and which options should I purchase?

Will this hardware suffice for the switch to BE 2014?

Thanks in advance for any assistance


Upgrading from Backup Exec 12 (not 2012) to 2014

$
0
0
I need a solution

Hi,

After some advice. We are currently running Backup Exec 12 (not 2012) on a Windows 2003 server. The plan is to install a new 2008 server and put Backup Exec 2014 on it. I read some where that upgrading from 12 is not possible but 12.5 is OK. Would i have to upgrade to 12.5 beforehand or would it not matter because i'm building a new server? Is there any documentation regarding this that you could point me to.

Thanks,

Backup Exec 2014 HOTFIX 218257

$
0
0
I need a solution

After application of this hotfix through LiveUpdate, any/all incremental backup jobs of virtual machines acting as active directory domain controllers always end with exceptions with a resulting:  

"V-79-57344-38747 - Backup Exec was unable to prepare Microsoft Active Directory resources for Granular Recovery Technology (GRT) operations.  Therefore you will be unable to perform GRT-enabled restores of Microsoft Active Directory data from this backup."

If I run a full backup, no issues.  As soon as an incremental runs, this happens 100% of the time.  If I uncheck Active Directory GRT, no issues...both full and incrementals will run without issue, no exceptions or failures.

I know without a doubt it is because of this hotfix, as I have taken a completely clean lab environment and installed base Backup Exec 2014, and running a GRT AD full and incremental backup completes 100% of the time.  As soon as hotfix 218257 is installed, all the incrementals complete, but now with the above exception, every time they are run.

I have had a ticket with Symantec open for 3+ weeks now, we no engineer calling me back.  So at this point, I'm a bit fed up with Symantec's support and am hoping someone else is seeing this and has been able to solve it.  If push comes to shove I will just revert to doing straight VM backups with dedupe, and if AD gets messed up, I will just restore to last full + incrementals.

Our Backup Exec server is:

Windows 2008 R2 Standard
32 GB of RAM
24 TB SAN
Backup Exec 2014 V-Ray Edition, hotfix 218257 installed

Our VM technology is:

VMware vSphere 5.1 accessed via vCenter, update 2

 

 

Last monthly Full Backup job failed with repercussions for subsequent weeks

$
0
0
I need a solution

Hello,

Unfortunately last month we had backup issues with our last Friday of the month Full Monthly Backup, (dated 27/06) the tapes were not changed and thus the Monthly backup consisting of 3 jobs did not run. The Monthly job tried to run on the Daily 4 tape which already had data written to it and as there was no admin input, it cancelled after a while. The other sheduled job on 28/06 was also automatically cancelled.

1.jpg

The following week, Daily Sets 1-4 (Mon to Thurs. respectively) ran with partial success, with only 2 of the 3 jobs succeeding. The week after the failed monthly job (05/07) the 3rd job was automatically cancelled even though the correct Weekly tape was inserted into the drive.

2.jpg

The following week (beginning 07/07 diagram above) the daily jobs ran normally between the 7th to the 10th. On the 11th a LiveUpdate was ran and the server was not restarted post installation, which caused the job cancellations on Monday 14th. This also caused the 6 missed jobs. The issue was reported to Symantec, who unfortunately misdiagnosed the problem and then asked us to try changing the Media Insert alert category properties to 'Respond with Yes/No' instead of Cancel, which had the consequence of generating 3000+ alerts between the Saturday 18th and Monday 20th when we had to manually cancel the backup job as to be able to run the day's Daily Backup job. This was reverted. The daily backup jobs then ran normally Monday night and Tuesday night.  Below is the monthly schedule for the up and coming Monthly backup on Friday.

3.jpg

The daily and weekly updates in this instance are superseded by the scheduled monthly updates.

The question is, what exactly has happened to our schedule because of a) the correct tape not being inserted last month and b) another instance of backup service being disturbed due to services not being available, and how do we revert the status quo and then ensure the job runs through correctly?

Thank you

 

GRT restores

$
0
0
No
I need a solution

Semi-related, not trying to hijack the thread:  I am looking to make a case for the VMWare agent vs. the RAWS agent methodology for our backup strategy.

Aside from the above advantages - and without having any deduplication licenses - Are there any space savings recognized by using the VMWare agent / VM backup method in place of a basic RAWS backup?
(ie.  Backing up the same Windows server using both methods, will one backup-set be decidedly smaller?)

Not having the VMWare license or a budget for it, I have not been able to benchmark the two methods for identifying any differences.

Also, is there any advantage to having the VMWare license for VMWare level backups in conjunction with the Application & Database license?  If using the VMWare level backup method provides the ability to restore individual files, then we should be able to restore SQL database files if needed?
Or, (I'm guessing here) the VM level backup will not truncate the SQL logs during the backup, so any SQL data file backed up using the VMWare method might not be restorable, unless the database was backed up by SQL and then the SQL generated database.bak file could be restored independantly.
And - Same question regarding Exchange DBs - If using only VMWare level backups do we lose the ability to perform GRT restores?

 

              Much appreciated,

0
10337851

BE2014 upgrade failing on migration

$
0
0
I need a solution

Hi All,

 

I'm trying to upgrade our BE2012 server to BE2014 and am getting an error during the migration phase of the upgrade stating that the database cannot be upgraded.  In the error log I can see errors as below:

07-24-2014,10:42:16 : dbutil RunSQLScript: dbupgrade14.0.sql SQLServer:BACKSQL01 SQLInstance:BACKUPEXEC DatabaseName:BEDB
07-24-2014,10:42:16 : OpenFromInitializationString Connection String = Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=BEDB;Data Source=BACKSQL01\BACKUPEXEC;Locale Identifier=1033;Application Name=BEWS DBUTIL hr=0x0
07-24-2014,10:42:19 : The statement has been terminated.
07-24-2014,10:42:19 : String or binary data would be truncated.
07-24-2014,10:42:19 : dbutil RunSQLScript: execute sql cmd failed. sql statement: UPDATE JHD Set JHD.ResourceDisplayName = RES.ResourceName FROM dbo.[JobHistoryDetail] JHD INNER JOIN dbo.[Resource] RES ON JHD.ResourceID = RES.ResourceID WHERE JHD.ResourceDisplayName = ''
07-24-2014,10:42:19 : dbutil RunSQLScript:Stop execution sql script
07-24-2014,10:42:19 : dbutil RunSQLScript: failed: 0x80040e57
07-24-2014,10:42:19 : OS ERROR: 0x80040e57 (-2147217833)
07-24-2014,10:42:19 : upgrade14x ends rc=1
07-24-2014,10:42:19 : Job Migration Failed
+ 07-24-2014,10:42:19 : Failure 1 running migration library 1
07-24-2014,10:42:19 : Destructor BEMigrate Freeing library: D:\Program Files\Symantec\Backup Exec\Migration\pvlupgrade.dll
07-24-2014,10:42:19 : Destructor BEMigrate Freeing library: D:\Program Files\Symantec\Backup Exec\Migration\jobmigration.dll
07-24-2014,10:42:19 : Destructor BEMigrate Freeing library: D:\Program Files\Symantec\Backup Exec\Migration\catupgrade.dll
07-24-2014,10:42:19 : Destructor BEMigrate Freeing library: D:\Program Files\Symantec\Backup Exec\Migration\pvlupgrade.dll
07-24-2014,10:42:19 : Destructor BEMigrate Freeing library: D:\Program Files\Symantec\Backup Exec\Migration\postmigrationprocessing.dll
+ 07-24-2014,10:42:19 : BE Migration Tool execution failed
07-24-2014,10:42:19 : Migration returned value: 1
07-24-2014,10:42:19 : Bemig returned
07-24-2014,10:42:19 : Migration failed returning error: 1

 

The only KB article I can find relating to this is here:

http://www.symantec.com/business/support/index?pag...

This is for BE2012 however and does not seem to match my logs.

 

Anyone else had this issue before and able to resolve?

 

Thanks

Backup Exec 2014 VMware backup sets don't display correct size on disk

$
0
0
I need a solution

Hello, I am using Backup Exec 2014 to back up VMs hosted on VMware ESXi 5.1 servers, and using the Backup Exec VMware Agent through the related vCenter management server. This is proving to be much faster for full server backups than backing up through the client agent directly (5.5 hours down to 2.5 hours in once case), so great.

But I'm seeing inconsistent size data in the VMware backup jobs. The VMs use thin provisioned disks and I have set up VMware change block tracking and confirmed this is working. When the backup actually happens, the backup job shows that only the actual allocated data on the server is backed up, not the full possible size of the virtual machine's disks:

e.g.

Backed up 0 files in 4 directories.
Backed up 1 virtual machines
Backed up 2 virtual machine disks
Processed 280722373259 bytes in  2 hours,  36 minutes, and  0 seconds.
Throughput rate: 1716 MB/min
Encryption Type: Software

This is 261 GB of data, which matches what is actually allocated on the VM.

Also, the entire job's byte count (which includes a few other things besides this server) is at 276 GB, also showing a reasonable total.

But when I look at the backup device (a USB disk) "Backup Sets" list and find this VM backup, the size of the backup is listed as 620GB, which is the maximum possible size of the VM's disks including empty unallocated space.

When I look in the USB disk's BEData folder and locate the related IMGxxxxx folder, I see servername.vmdk files that are collectively 257 GB in size, so it seems the actual backup device disk storage is correct.

But I'm not sure what other things in Backup Exec might be led astray, if any, by the incorrect size report in the backup sets list. At least, it makes it difficult for me to do retention time planning as I use the backup set list sizes to do this.

Anyone run into this?

Thanks,

Tim Miller Dyck

Ontario, Canada

 

 

 

backup exec 2012

$
0
0
I need a solution

good morning, 
I have to add the linux agent from backup exec 2012 to a linux server, my question is if anyone has any procedure to install the agent on the linux server using linux. 
thank you for your support


Automatically transferring disk backup media files to offsite location

$
0
0
I need a solution

We are looking into completely revamping our backup practices, including moving away from tape media.

Our goals are to perform (deduplicated) backups to onsite disk storage, AND THEN automatically transfer the disk-based media sets to an offsite location over a L2L VPN connection. We haven't worked out the exact rotation details yet, but the most recent backups should be available both on and offsite.

As we are planning to purchase Backup Exec 2014 (with appropriate Agents and the Dedup option), we'd like to know if that offsite transfer can be automated with Backup Exec.

If not, are there any suggestions as to another tool that would help us accomplish this?

Thanks for any input,

Warren Schubert

How to set incremental to run between specific times - Backup Exec 2012

$
0
0
I need a solution

Hi all, not sure if this can be done but I figured this would be the place to ask.

 

My client is running Backup Exec 2012 on a Windows 2008 R2 Standard box.  They back up their SQL 2008 R2 Standard database every evening at 2am.  They would like to run incremental backups on the database every 30 minutes starting at 8:30am and going until 1:30am, and then the full will run at 2am as normal.  They would also like the incrementals to be deleted after the full runs, as they only need them in case something needs to be restored during the day.

 

Is there a way to set the incremantals to only run from 8:30am until 1:30am?  I have it scheduled to run every 30 minutes but that keeps going between 2am and 8:30am, which they don't want.  I set the "Keep for" set for 1 day for the incrementals, so I'm hoping it overwrites the old ones.

 

Any help would be appreciated!  Thanks!

Dedup backups for VHDX

$
0
0
I need a solution

On Backup Exec 2014 is backup to dedup supported for VHDX ?

2012 SP4: Agent Linux Oracle problem

$
0
0
I need a solution

Hello,

I have problem with credential test - see image below.

oracle.png

I used AgentConfig to configure database and instance access with another account. Configured account backupexec for system access and be_backup for Oracle DB access and it seems to be OK:

b576d700 Thu Jul 24 13:02:13 2014 : OCIINTERCONNECT::LogonOracle: db = (a), home_dir = (/), user =(b), passwd= (****)
b576d700 Thu Jul 24 13:02:13 2014 :  Current Oracle user name (be_backup)
b576d700 Thu Jul 24 13:02:13 2014 : putenv(ORACLE_SID=adb11)
b576d700 Thu Jul 24 13:02:13 2014 : putenv(ORACLE_HOME=/opt/oracle/product/11.2.0/adb11)
b576d700 Thu Jul 24 13:02:13 2014 : OCIServerAttach() Linux 1
b576d700 Thu Jul 24 13:02:13 2014 : OCIINTERCONNECT::LogonOracle: Logon is successful
b576d700 Thu Jul 24 13:02:13 2014 : OCIInterconnect: Logon Successful
b576d700 Thu Jul 24 13:02:13 2014 : OCIINTERCONNECT::OracleIsRAC:- tq = select PARALLEL  from v$instance where instance_name='adb11' Sidname = adb11
b576d700 Thu Jul 24 13:02:13 2014 : OCIINTERCONNECT::OracleIsRAC: query = (select PARALLEL  from v$instance where instance_name='adb11')
b576d700 Thu Jul 24 13:02:13 2014 : CONFIG_ORACLE_ISRAC,TEXT(NO)
b576d700 Thu Jul 24 13:02:13 2014 : I Linux: SIDName adb11 is not part of RAC. Seems to be a normal setup. Adding DLE
b576d700 Thu Jul 24 13:02:13 2014 : OCIInterconnect: logoff successful

But in Oracle log, I found that user ROOT was trying to login:

24-JUL-2014 13:02:13 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=adb11)(CID=(PROGRAM=beremote)(HOST=adb-o11g)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.10.10)(PORT=47388)) * establish * adb11 * 0

24-JUL-2014 13:02:13 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=adb11)(CID=(PROGRAM=beremote)(HOST=adb-o11g)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.10.10)(PORT=47389)) * establish * adb11 * 0

I've used SGMON and beremote --log-console to find a cause of that problem but no luck.

Server and agent are both 2012 SP4 version. Agent runs on RHEL 6 and Oracle 11gR2.

 

 

Backup Exec credentials

$
0
0
I need a solution

In upgrading from 2012 to 2014, Symantec has taken away the ability to have different logn credentials for various databases on a server. It now will only take the server login account for authentication for SQL databases.  We were told that this was a Micrsoft required change which we don't believe is correct as Microsoft SQL authentication vs active directory autentication to the server in their own products such as Microsoft Dynamics.  You have to be able to select different login accounts for the server you are backing up and the SQL databases on that server.  We will be investigating CommVault at VMWorld.  If anyone has any feedback on this issue, please post.

Viewing all 7183 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>