<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Forget NDMP & use Synthetic Full backups</title>
		<description>Discuss Forget NDMP & use Synthetic Full backups</description>
		<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html</link>
		<lastBuildDate>Fri, 10 Feb 2012 10:49:26 +0000</lastBuildDate>
		<generator>JComments</generator>
		<atom:link href="http://www.backupcentral.com/component/jcomments/feed/com_content/48/10.html" rel="self" type="application/rss+xml" />
		<item>
			<title>yaron says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-26</link>
			<description><![CDATA[Hi, From my exprience, LAN based NDMP is 2-3 times faster than NFS based backup. In my setup, the Networker server and the library are located at a DR room, over a kilometer away, so pulling fibers just for connecting drives to the filer is not an option. There are a few problems with your argument about dump. Dump handles correctly the issue of not restoring files which were DELETED. tar/cpio cannot do that. Linus, when speaking of dump's data corruption, is probably refering to dumps of a mounted file system. This is something you shouldn't do in the first place. As for NDMP usage of dump, you might recall that when running dump of a NetApp, the filer takes a snapshot and backs it up. This should guarantee that the dump will not be corrupted.]]></description>
			<dc:creator>yaron</dc:creator>
			<pubDate>Fri, 04 May 2007 16:05:42 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-26</guid>
		</item>
		<item>
			<title>VTLs?</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-18</link>
			<description><![CDATA[This actually came from ag100. Had a problem with his post.. Hey - It goes without saying, but I think this really depends on individual environments and requirements... From my experience, larger environments with a mix of NFS, CIFS and multi-protocol shares, this has a hard time scaling. It's also added complexity and removed some key benefits seen using NDMP (not that I'm completely thrilled with NDMP, either). Here's why: * You generally (perhaps not in all cases) have to specify save set names manually, instead of using an "All", when backing up remote file systems. If you have a lot of file systems (or a growing environment), this increases the possibility of someone forgetting to add a file system and increases the inherant the risks associated with human interaction (typos, etc...). Now that some backup software no longer requires you to specify each file system individually, (assuming your volumes are sized reasonably, etc...) using "All" can be a nice feature, which also reduces risk. Along the same lines, if your filer has a lot of save sets, you can run into limitations in your backup software... For example, I believe NetWorker only supports ~900 bytes in a save set listing and 1024 bytes per client profile. If you run over that, you're stuck managing multiple client profiles per client, or using scripts to issues save commands manually. * Another item that must be considered, depending on requirements, is the network. Local NDMP backups, which takes advtantage of disk (via VTL) or modern tape technology perform can perform relatively well. If you had a requirement to backup file systems with a high data change rate (pst's, databases, etc...), you might find that performing even daily incremental backups can put considerable strain on backup resources. * If you have both NFS and CIFS shares, you may have to have UNIX and Windows tape servers available. That can be painful, especially if you don't have both in your environment now. * Lastly, we've been receiving an increasing number of requests for multi-protocol shares. As you mentioned, due to permissions requirements, this is a known limitation of network based backups NAS backups. I'm not bashing the idea, and for some environments, it's a perfect fit, it just hasn't scaled well for me in the past. Thoughts? -Aaron]]></description>
			<dc:creator>cpreston</dc:creator>
			<pubDate>Tue, 01 May 2007 11:24:32 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-18</guid>
		</item>
		<item>
			<title>Just throwing out an idea</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-19</link>
			<description><![CDATA[Just threw out an idea to get us talking. Thanks for the feedback. I agree with pretty much everything you said. (I'm not sure if you can use All with NDMP either, depending on your backup software, but I get your point.) I've backed up some of the biggest NAS environments out there and have done some pretty "kooky" things that others said wouldn't scale, and they did, so I have a little more faith than the average joe about what will work in a large environment. You might be surprised as to how well this will scale. Summary: Just think about my idea. If it works for you, then cool!]]></description>
			<dc:creator>cpreston</dc:creator>
			<pubDate>Mon, 09 Apr 2007 17:21:49 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-19</guid>
		</item>
		<item>
			<title>cpreston says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-16</link>
			<description><![CDATA[You're exactly right that the same utility /format will be used to create the synthetic backup. However, if you're going to be doing synthetic fulls, you're not going to use NDMP; hence, you're not going to use dump. So here are your two choices: * dump with regular occasional &#34;real&#34; fulls * NFS/CIFS -> server -> some commercial utility, followed by occasional synthetic fulls And I'm saying that the latter has the following advantages: * It doesn't use dump (which has had problems since it was designed) * It allows you to perform fulls whenever you want, even during the day * It places no load on the filer or LAN when you're doing synthetic fulls So I'm saying give it a shot!]]></description>
			<dc:creator>cpreston</dc:creator>
			<pubDate>Thu, 22 Mar 2007 11:00:05 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-16</guid>
		</item>
		<item>
			<title>hga says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-13</link>
			<description><![CDATA[No, not at all. I have no love for dump, and I don't think I've used it since 1987 or so (4.2 or .3 BSD on MicroVAX IIs). As for the comments by Linus, which I think you mention in your newest book, I'm not at all impressed: in essence what he's saying is that it was decided not to carry dump along with Linux by the time of the 2.4 kernel (perhaps a good decision, but &#34;cpio/tar&#34;, while good archivers, are no substitute for the real thing), and that no replacement was even envisioned as of 2001, and from your book, none has been made. For someone who worked with systems like MULTICS, history is repeating itself as a farce, where we are developing systems that are pale shadows of what we once did.... Anyway, in all cases I'm assuming the same utility was used to collect the original backups, and that the synthetic full is made to look like it was made with the same utility. I'm a programmer who sometimes wears a sysadmin hat, and who knows how easy it is to create bugs, and how few organizations really test the software they ship. Hopefully commercial backup vendors do an above average job, but you would know that much better than I. Me, I'm with Jacques Clouseau in I think the Return of the Pink Panther: "I suspect everyone, and I suspect no one." - Harold]]></description>
			<dc:creator>hga</dc:creator>
			<pubDate>Thu, 22 Mar 2007 08:41:52 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-13</guid>
		</item>
		<item>
			<title>cpreston says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-14</link>
			<description><![CDATA[Any backup can have bugs. Are you saying that you'd prefer the known bugs and hiccups of dump to unknown (possible) bugs in synthetic full? Have you ever read or heard what Linux Torvalds is saying these days about dump? (http://lwn.net/2001/0503/a/lt-dump.php3 Here's a few excerpts: &#34;-)ump was a stupid program in the first place. Leave it behind.&#34; &#34;Right now, the cpio/tar/xxx solutions are definitely the best ones ... Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of dump.&#34; (Dump is what NetApp and a few other NAS vendors use underneath NDMP, BTW.)]]></description>
			<dc:creator>cpreston</dc:creator>
			<pubDate>Wed, 21 Mar 2007 15:27:57 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-14</guid>
		</item>
		<item>
			<title>hga says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-12</link>
			<description><![CDATA[One is making a bet that your vendor will properly construct a synthetic full backup. Bugs in that might be a bit subtle to detect, and it probably would be a good idea to keep the real full backup and incrementals until you make another real full backup. Otherwise, if time to restore from a total failure is important, it sounds like a great idea. - Harold]]></description>
			<dc:creator>hga</dc:creator>
			<pubDate>Wed, 21 Mar 2007 15:12:31 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/48-forget-ndmp-a-use-synthetic-full-backups.html#comment-12</guid>
		</item>
	</channel>
</rss>

