Import tapes written by other software

[futureweb]

Hi,

we are in the process of migrating from DPM.
As we want to be sure to be able to restore DPM files, which should be possible, we did try it with an error (Invalid Data).

But we believe, that we have an error in the catalog.
Each tape we load and inventory is recognized with the exact same Media Set, no matter if the tape is 1 week or 1 year old, which just can't be true as DPM adds a unique Nr- at the end of the SET name.
We also read the MTF Header and there the Media Set Name of DPM is correct and different.

Code: Select all

MTF Media Label|1.0|Microsoft|4.2.1312.0|2015/08/22.08:49:22|Vix Backup Volume-LT-1Tage-Copy0-00000191|0|{eb9a80c2-16d1-4600-b639-c064f5ad3623}|{c5d933e4-8ca5-4059-bf06-4ec1245c093c}|
MTF Media Label|1.0|Microsoft|4.2.1235.0|2014/09/01.04:33:10|DPM Backup-LT-1Monate-Copy0-00000017|0|{2718d44d-5540-4b36-9be0-feb990b9d3bc}|{c5d933e4-8ca5-4059-bf06-4ec1245c093c}|

Also after the tape was catalogued, all show always the exact same file tree in the file browser, and always show only one restore point, even there are more, which looks like, that it's the catalogue of the Set itself.

Probably the problem is, that the last ID within the header is the same on all DPM Tapes?

Code: Select all

{c5d933e4-8ca5-4059-bf06-4ec1245c093c}

I have to mention, that we are using the "Optimize Tape Usage" Option within DPM 2012 if that helps.

So any hint what the problem could be that we are able to restore files done within DPM?


Thanks
Patrick

[veremin]

Are you willing to make VB&R read tapes written by DPM? If so, it's not possible. Thanks.

[futureweb]

Hello,

your Statement doesn't match the Information within VEEAM User Guide --> http://helpcenter.veeam.com/backup/80/h ... tapes.html
According to this it should be no problem to import / restore Tape Backups made with DPM! (they are MTF Format)

VB&R does recognize the DPM Tapes ... the Problem is that VB&R thinks they all belong to the same Media Set - even if they don't ... so it's using the wrong Tape Catalogue for different Tapes ...

As far as I can tell this is a Bug within VB&R - see the MTF Headers we posted in the inital posting.

Thank you
Andreas Schnederle-Wagner

[veremin]

The implementation of MTF might vary between vendors. For instance, DPM uses slightly different implementation of MTF, than NT Backup does. Thus, restore from such tapes is not possible.

Though, you might want to reach support team, they might be aware of creative workarounds addressing your issue.

Thanks.

[Dima P.]

Patrick,

That is true - quick check on the DPM’s tape media co-location feature makes me think that it somehow adjusts the MTF (maybe some additional info in the media header, can say exactly I am not an DPM expert). Keeping this in mind and looking at the error you've posted that makes sense to me.

Can you clarify is it possible to leave a DMP solution in-hose for recovery purposes only and start using the retired DPM written media within Veeam B&R? Thanks in advance for your answer.

[futureweb]

I did a case: 01039503
While prior to evaluation we found this posting where DPM was stated as possible as it uses MTF, that's why we are confused, if we migrate to Veeam, it's kind of important to have access to old backups.
http://forums.veeam.com/tape-f29/restor ... 19413.html

Hopefully there is a "creative workaround"... as last DPM Tapes would expire in 12 months...

[futureweb]

Patrick,

That is true - quick check on the DPM’s tape media co-location feature makes me think that it somehow adjusts the MTF (maybe some additional info in the media header, can say exactly I am not an DPM expert). Keeping this in mind and looking at the error you've posted that makes sense to me.

Can you clarify is it possible to leave a DMP solution in-hose for recovery purposes only and start using the retired DPM written media within Veeam B&R? Thanks in advance for your answer.

Well: Microsoft uses the last ID as "Domain" for the whole server, as mentioned in the specifications. While Veeam uses this ID to identify the Media Set.
So Veeam thinks, DPM Tapes are all the same media set and that breaks things one the first DPM Tape was read.

We are able to use retired DPM written Data, that was already tested, but we didn't want to keep DPM as retired solution, as we are switching the complete Backup server, and that DPM would have access to Tapes we would need to be installed on the root server itself,
and the software package is pretty big, also I am not sure about Tape Locking, DPM does daily inventories and stuff and I know Veeam is pretty picky if anything on the tape changes. So this is a solution we wanted to avoid, especially as the error just seems to be using one ID, that doesn't differ on DPM, and does differ on Veeam.

The data is there, just the catalog within B&R isn't done correct, as it references always to the first recognized DPM tape. So not sure if there is any other easier solution than having to use DPM fully again and always be careful to switch tapes.
If this ID Problem wouldn't exist, it would even be perfect, as it would recognize even all recovery points from DPM.

[Dima P.]

Hello Patrick,
Thank you! Even if support team somehow succeeds you still have to manage those tapes manually and once the retention is reached manually erased it within Veeam B&R console.

Can I ask what and how much data you store on the DMP written media? Could it be a good idea to restore it and then backup via Veeam’s file to tape job – leaving the full tape management and rotation to Veeam B&R console?

Meanwhile, we will discuss with the team if it’s a good idea to remove all the references to such support: MTF format is modified and adjusted almost by any vendor in the field, thus we cannot guarantee such tapes are restorable.

[futureweb]

Hi,
well, if we are unable to find a solution, we will have to think of doing it any other way.
Haven't checked yet if any Software exists, that can just read MTF Tapes and gets data of the disk.

But still it's a pitty, as I believe its just an ID issue. Why aren't foreign MTF Volumes just matched by the barcode, which has to be unique.

About dropping foreign MTF Support, I must admit, it was one of the first things I checked when starting to test your software,
not sure how others think but usually, even if it's a more uncomfotable way, any upgrade path is good as it let's you easier switch
to a new solution.

Manual handling of retention is already prepared by us, a simple excel that's needed for 1 year, we also wouldn't catalog all tapes, just if a restore is necessary.

About restoring all, we are talking about 70-80 Tapes here, if I remove all 8 week retentions about 50.

Most probably we won't need them anyway so the effort wouldn't really be worth it. Especially as we can't partition the MSL
as Veeam would recognize it as new library (at least until v9 is out). Thus meaning to stall all tape backups until all is restored.

Archived data (that doesn't have retention) will be moved freshly to veeam but luckily, here we only talk about 5 Tapes.
And I also like the file window that shows the complete tree and makes life easier, if you look for archived data later on and know where it resides.
(OT: Too bad you can only search after file names and not folder names, and that you can't easily say, make 2 copies of each data).

So thanks for your reply and try to get it solved, I will update the case with all logs that you need and we see, if anything could be settled out,
otherwise I am sure we will find any appropriate way for worst case.

Thanks
Patrick

[Dima P.]

Hello Patrick,

Thanks for the provided troubleshooting information! We are investigating your case with the support team – will see how it goes. Stay tuned.

[SintLodewijk]

Hello,

Sorry to respond to this old thread, but we have a similar problem in our organisation.

Is there a solution or workaround for restoring from old DPM tapes ?

[Dima P.]

Hello SintLodewijk,

Unfortunately, 3rd party tapes are no longer supported due the wide verity of MTF implementations - please use the native tools to restore the tape media. Thank you.

[SintLodewijk]

Thank you for the quick response.

[veremin]

It wouldn't harm to use previous software to restore that data and re-backup it, now with the use of VB&R. Just to have everything at hand within one backup server. Thanks.

[teratoon]

Hello

Veeam 9 does'nt recognize DPM tapes, because they use same MediaFamily ID and MediaSequence number as DPM - Drive ID: Tape0) Error: Duplicate tapes with the same family id (1) and sequence number (1). I want a make Feature Request for Future release, that can change Veeam tape MediaFamily ID and Sequencenumber, then Veeam would recognize them. i Already spoke with your Support and they Suggest to make that feature request - Case # 01697780. Then would move from DPM to Veeam much easier.

Raiko

[veremin]

Veeam 9 does'nt recognize DPM tapes

That's expected due to various MTF implementations. Thanks.

[wilkins44]

We are about to take on a few other groups' servers and backup infrastructure. Is there a way to convert and import the existing backups on tape for the other backup software? As of right now, we are going to be inheriting some DPM, TSM, Backup Exec, Commvault, and a few others. We don't want to keep all of the other software packages, but don't want to lose all of the existing backups.

Thanks.

[mfinnigan_g]

Seconding this request - we have migrated from Commvault to Veeam, but still are maintaining our old Commvault infrastructure in case we need to restore from our old tapes.

[DaveWatkins]

Mostly no. Veeam supports reading MTF tapes, which mist other backup applications use, but they all add some custom stuff which makes them unreadable to other applications (I often wonder if this is intentional).

Your options are either to restore the tapes to local storage, then back them up with Veeam, or maintain the old software in case you ever want to restore. Neither of which is a pleasant thought I know :/

[veremin]

It's highly unlikely that we'll have this functionality due to the fact that MTF implementations vary from vendor to vendor. Thanks.