NDMP is a backup control protocol, but it's not a data format. Even ONTAP has multiple formats for NDMP backups. In the first release of NDMP, the backup was a near mirror of ufsdump, and it was pretty easy to restore an ONTAP backup to something like Solaris. You'd get some weird permissions, but it did work.
The problem with ufsdump formats is the controller has to create the files and stream them off to the backup destination. About 10 years back, ONTAP added the ability to do NDMP backups using a snapmirror format. It was just the raw WAFL data, and it was WAY faster. It also meant that unless a system could real WAFL, there would be no way to use those backups. It was a nice option for full backups with a low chance of needing to be recovered, because recovery would requiring restoring the entire volume object that you backed up.
Snapdiff allows a backup application to do incremental-forever backups. It could ask ONTAP to identify changed files from the previous backup and provide the list of files to be backed up to the backup app, which would be read from an NFS/SMB share. I didn't think NDMP was involved.
Does the Rubrik documentation mention a NFS or SMB share path?
If the ONTAP system went away someday, I would expect you could use a Cloud Volumes ONTAP instance in Azure or AWS to restore the data. There used to be some sort of limitation with NDMP and CVO, but I can't see why Snapdiff wouldn't work as usual on CVO. I'll ping a couple of guys...
From: Toasters toasters-bounces@teaparty.net On Behalf Of Heino Walther Sent: Saturday, April 10, 2021 5:34 AM To: Brian Parent bparent@ucsd.edu; toasters@teaparty.net Subject: SV:
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
As fas as I can remember snapdiff is using NDMP which should be a standard and open protocol, but NetApp, EMC and others have made their specific changes to their version of NDMP which basically make them not interchangeable. So I guess you will need a NetApp controller in order to restore your data. There is a slim chance that files can be restored to other NDMP devices (CIFS or NFS), but LUNs are required to be restored to a NDMP.
You can either just keep a NetApp controller ready for this (with no service on it) or maybe just setup an ONTAP Select virtual instance in vSphere which you will be able to restore to, and it's not as expensive and a NetApp Hardware box.
/Heino
Fra: Toasters <toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net> på vegne af Brian Parent via Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Dato: lørdag, 10. april 2021 kl. 02.12 Til: toasters@teaparty.netmailto:toasters@teaparty.net <toasters@teaparty.netmailto:toasters@teaparty.net> Emne: <no subject> _______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
CVO and CBS specifically, from what I understand is snapdiff based. On Sunday, April 11, 2021, 09:46:36 AM CDT, Steiner, Jeffrey jeffrey.steiner@netapp.com wrote:
<!--#yiv1059018887 _filtered {} _filtered {}#yiv1059018887 #yiv1059018887 p.yiv1059018887MsoNormal, #yiv1059018887 li.yiv1059018887MsoNormal, #yiv1059018887 div.yiv1059018887MsoNormal {margin:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv1059018887 a:link, #yiv1059018887 span.yiv1059018887MsoHyperlink {color:blue;text-decoration:underline;}#yiv1059018887 span.yiv1059018887EmailStyle20 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv1059018887 .yiv1059018887MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv1059018887 div.yiv1059018887WordSection1 {}--> NDMP is a backup control protocol, but it's not a data format. Even ONTAP has multiple formats for NDMP backups. In the first release of NDMP, the backup was a near mirror of ufsdump, and it was pretty easy to restore an ONTAP backup to something like Solaris. You'd get some weird permissions, but it did work.
The problem with ufsdump formats is the controller has to create the files and stream them off to the backup destination. About 10 years back, ONTAP added the ability to do NDMP backups using a snapmirror format. It was just the raw WAFL data, and it was WAY faster. It also meant that unless a system could real WAFL, there would be no way to use those backups. It was a nice option for full backups with a low chance of needing to be recovered, because recovery would requiring restoring the entire volume object that you backed up.
Snapdiff allows a backup application to do incremental-forever backups. It could ask ONTAP to identify changed files from the previous backup and provide the list of files to be backed up to the backup app, which would be read from an NFS/SMB share. I didn't think NDMP was involved.
Does the Rubrik documentation mention a NFS or SMB share path?
If the ONTAP system went away someday, I would expect you could use a Cloud Volumes ONTAP instance in Azure or AWS to restore the data. There used to be some sort of limitation with NDMP and CVO, but I can't see why Snapdiff wouldn't work as usual on CVO. I'll ping a couple of guys…
From: Toasters toasters-bounces@teaparty.net On Behalf OfHeino Walther Sent: Saturday, April 10, 2021 5:34 AM To: Brian Parent bparent@ucsd.edu; toasters@teaparty.net Subject: SV:
| NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
As fas as I can remember snapdiff is using NDMP which should be a standard and open protocol, but NetApp, EMC and others have made their specific changes to their version of NDMP which basically make them not interchangeable.
So I guess you will need a NetApp controller in order to restore your data.
There is a slim chance that files can be restored to other NDMP devices (CIFS or NFS), but LUNs are required to be restored to a NDMP.
You can either just keep a NetApp controller ready for this (with no service on it) or maybe just setup an ONTAP Select virtual instance in vSphere which you will be able to restore to, and it’s not as expensive and a NetApp Hardware box.
/Heino
Fra:Toasters toasters-bounces@teaparty.net på vegne af Brian Parent via Toasters toasters@teaparty.net Dato: lørdag, 10. april 2021 kl. 02.12 Til: toasters@teaparty.net toasters@teaparty.net Emne: <no subject>
_______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters _______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
Thanks Jeff, excellent answer with good details, as always! I myself agree with this: "but I can't see why Snapdiff wouldn't work as usual on CVO."
The connection b/w SnapDiff and NDMP isn't clear to me (either).
Will be interesting to see the response to your "ping".
/M
-------- Original Message --------Jeffrey Steiner wrote: NDMP is a backup control protocol, but it's not a data format. Even ONTAP has multiple formats for NDMP backups. In the first release of NDMP, the backup was a near mirror of ufsdump, and it was pretty easy to restore an ONTAP backup to something like Solaris. You'd get some weird permissions, but it did work.
The problem with ufsdump formats is the controller has to create the files and stream them off to the backup destination. About 10 years back, ONTAP added the ability to do NDMP backups using a snapmirror format. It was just the raw WAFL data, and it was WAY faster. It also meant that unless a system could real WAFL, there would be no way to use those backups. It was a nice option for full backups with a low chance of needing to be recovered, because recovery would requiring restoring the entire volume object that you backed up.
Snapdiff allows a backup application to do incremental-forever backups. It could ask ONTAP to identify changed files from the previous backup and provide the list of files to be backed up to the backup app, which would be read from an NFS/SMB share. I didn't think NDMP was involved.
Does the Rubrik documentation mention a NFS or SMB share path?
If the ONTAP system went away someday, I would expect you could use a Cloud Volumes ONTAP instance in Azure or AWS to restore the data. There used to be some sort of limitation with NDMP and CVO, but I can't see why Snapdiff wouldn't work as usual on CVO. I'll ping a couple of guys...
I got the answer from one of our technical directors. Yes, if the original ONTAP system went away, you should be able to restore the Rubik backups to a Cloud Volumes ONTAP instance. The SnapDiff API works as usual. The fact it's CVO rather than a physical ONTAP system is pretty much irrelevant.
I'd recommend double-checking this with Rubik in case they have some unexpected limitation, such as licensing. The technology should be fine.
From: Steiner, Jeffrey Sent: Sunday, April 11, 2021 9:39 AM To: Heino Walther hw@beardmann.dk; Brian Parent bparent@ucsd.edu; toasters@teaparty.net Subject: SnapDiff/Rubrik
NDMP is a backup control protocol, but it's not a data format. Even ONTAP has multiple formats for NDMP backups. In the first release of NDMP, the backup was a near mirror of ufsdump, and it was pretty easy to restore an ONTAP backup to something like Solaris. You'd get some weird permissions, but it did work.
The problem with ufsdump formats is the controller has to create the files and stream them off to the backup destination. About 10 years back, ONTAP added the ability to do NDMP backups using a snapmirror format. It was just the raw WAFL data, and it was WAY faster. It also meant that unless a system could real WAFL, there would be no way to use those backups. It was a nice option for full backups with a low chance of needing to be recovered, because recovery would requiring restoring the entire volume object that you backed up.
Snapdiff allows a backup application to do incremental-forever backups. It could ask ONTAP to identify changed files from the previous backup and provide the list of files to be backed up to the backup app, which would be read from an NFS/SMB share. I didn't think NDMP was involved.
Does the Rubrik documentation mention a NFS or SMB share path?
If the ONTAP system went away someday, I would expect you could use a Cloud Volumes ONTAP instance in Azure or AWS to restore the data. There used to be some sort of limitation with NDMP and CVO, but I can't see why Snapdiff wouldn't work as usual on CVO. I'll ping a couple of guys...
From: Toasters <toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net> On Behalf Of Heino Walther Sent: Saturday, April 10, 2021 5:34 AM To: Brian Parent <bparent@ucsd.edumailto:bparent@ucsd.edu>; toasters@teaparty.netmailto:toasters@teaparty.net Subject: SV:
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
As fas as I can remember snapdiff is using NDMP which should be a standard and open protocol, but NetApp, EMC and others have made their specific changes to their version of NDMP which basically make them not interchangeable. So I guess you will need a NetApp controller in order to restore your data. There is a slim chance that files can be restored to other NDMP devices (CIFS or NFS), but LUNs are required to be restored to a NDMP.
You can either just keep a NetApp controller ready for this (with no service on it) or maybe just setup an ONTAP Select virtual instance in vSphere which you will be able to restore to, and it's not as expensive and a NetApp Hardware box.
/Heino
Fra: Toasters <toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net> på vegne af Brian Parent via Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Dato: lørdag, 10. april 2021 kl. 02.12 Til: toasters@teaparty.netmailto:toasters@teaparty.net <toasters@teaparty.netmailto:toasters@teaparty.net> Emne: <no subject> _______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
-
Iluhes -
Michael Bergman -
Steiner, Jeffrey