Journal Based Backup FAQ?

2013-07-23 Thread Prather, Wanda
Does anybody happen to have a copy of the Journal Based Backup FAQ they could send me? As I recall it was very useful. It is still referenced many places on the support site, it used to be swg21155524, but that link is broken now. Thanks Wanda Wanda Prather | Senior Technical Specialist |

Re: Deduplication/replication options

2013-07-23 Thread Sergio O. Fuentes
Thanks, guys, for your input. Nick, your comment is relevant to us. We're not used to by-passing TSM for any storage management task regarding backups. We use very little storage-based replication in our environment as it is, and introducing array-based replication adds a wrinkle to managing our

Re: Deduplication/replication options

2013-07-23 Thread Nick Laflamme
I'm surprised by Allen's comments, given the context of the list. TSM doesn't support BOOST. It doesn't support at the server level, and it doesn't support for a client writing directly to a DataDomain DDR. This may be obvious to everyone, but I fear for the people who are TSM-centric and haven't

Re: Deduplication/replication options

2013-07-23 Thread Huebner, Andy
I have no experience with TSM de-dup, but I have plenty with Data Domain. We have 3 different disaster recovery methods for 3 sites. 1. The largest site is traditional TSM, write the data to a primary pool (DD VTL) and make copies to physical tape and use a truck to move them away. 2. Medium si

Re: Deduplication/replication options

2013-07-23 Thread Vandeventer, Harold [BS]
I'm using Data Domain as the only dedup component. Mgmt is balking at the cost additional disk or tape pools with TSM dedup and the highly desired "backup to non-dedup pool." Our current tape technology is quite old and replacing with several new drives and library hardware isn't on the financ

Re: Deduplication/replication options

2013-07-23 Thread Allen S. Rout
On 07/23/2013 01:19 PM, Sergio O. Fuentes wrote: > > We're currently faced with a decision go with a dedupe storage array > or with TSM dedupe for our backup storage targets. There are some > very critical pros and cons going with one or the other. For > example, TSM dedupe will reduce overall ne

Re: Deduplication/replication options

2013-07-23 Thread Arbogast, Warren K
Hi Sergio, There are many people more knowledgeable than I am on this topic, and I hope they contribute to this interesting question. My two cents would be to remember that the TSM database doesn't know about an array replication, so you'll have to deal with that issue if you have a massive reco

Re: TDP for Exchange 2010 DAG full database backup experiencing intermittent failures

2013-07-23 Thread Storer, Raymond
Steve, according to the link below parallel backups are supported; however, you should allow a minimum of ten minutes between backups. http://pic.dhe.ibm.com/infocenter/tsminfo/v6r4/topic/com.ibm.itsm.mail.exc.doc/c_dpfcm_bup_vssplan_exc.html Ray Storer NIBCO INC. -Original Message- Fr

Deduplication/replication options

2013-07-23 Thread Sergio O. Fuentes
Hello all, We're currently faced with a decision go with a dedupe storage array or with TSM dedupe for our backup storage targets. There are some very critical pros and cons going with one or the other. For example, TSM dedupe will reduce overall network throughput both for backups and replic

TDP for Exchange 2010 DAG full database backup experiencing intermittent failures

2013-07-23 Thread Schaub, Steve
Exchange 2010 w/DAG Tsm server 6.2.4 Tsm client 6.4.0.0 Tdp client 6.4.0.0 The script that runs our nightly full backups is having intermittent failures.  Different servers, different databases each night, but all the failures have the same API error message.  The way the powershell script works

SV: Export node question

2013-07-23 Thread Christian Svensson
Doesn't matter what order it does? Because you can't work with the data in mean will on the target server, and TSM will send over all Meta Data first between the two servers. /Christian -Ursprungligt meddelande- Från: Robert Ouzen [mailto:rou...@univ.haifa.ac.il] Skickat: den 18 juli 20