From owner-freebsd-questions@FreeBSD.ORG Thu Dec 4 05:13:50 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41E0C740 for ; Thu, 4 Dec 2014 05:13:50 +0000 (UTC) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE00D896 for ; Thu, 4 Dec 2014 05:13:49 +0000 (UTC) Received: from r56.edvax.de (port-92-195-18-117.dynamic.qsc.de [92.195.18.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 1131427615; Thu, 4 Dec 2014 06:13:40 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id sB45DeUQ004224; Thu, 4 Dec 2014 06:13:40 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Thu, 4 Dec 2014 06:13:40 +0100 From: Polytropon To: Paul Pathiakis Subject: Re: Backup solution for freeBSD/Symantec Backup exec porting Message-Id: <20141204061340.60bc8325.freebsd@edvax.de> In-Reply-To: <547FE590.1050403@yahoo.com> References: <999d7e80e60f466682c736f275b75788@Server02.ad.ezmax.ca> <547FE590.1050403@yahoo.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 05:13:50 -0000 On Wed, 03 Dec 2014 23:39:44 -0500, Paul Pathiakis via freebsd-questions wrote: > Disk is very cheap these days. Also, ZFS will let you know there's a > failure and you can rebuild. Digital tape over the years, may lose > information. (Yes, other people will tell you no way. However, do you > want to find out when trying to restore? - I'm speaking from > experience). The other issue is keeping the disk powered and online. > That's power and heat. More $$$ versus tape. At this point, it's worth reminding about the difference between backup and archive. For backups, disk-based solutions are the way to go today. For long-term storage, it's not fully sure that drives bought today will be usable in 10 years (mechanical failures and "blockages"). The solution for this problem is to copy the data from disk generation to disk generation. There is other media (optical, magneto-optical, optical) probably more suitable for long-term storage, but of course, those solutions are very specific and often don't map well to the requirement of storing thousands of GB of data. > Also, tape is a lot more mechanical than disk [...] Not the tapes themselves, but the drive. A slight error in the positioning of the drive mechanic may cause trouble, such as tapes being unreadable, or worse, tapes becoming "drive-specific", with the failing of the drive implying the unusability of the tapes. > [...] and it's sequential when > restoring. When someone needs something back... NOW is not soon enough > in most cases. Again, this is best solved with backup on disks, as the access can be achieved randomly (instead of sequencial). Furthermore, there is not the problem of size limitation to the tape (e. g., to restore a file that requires 2 tapes because of its size). > Also, there is a misconception about backups. Many vendors have > products that 'stream across' multiple media at a time. That is not a > good thing. It means that you can backup fast. However, it usually > means that all the drives that were streamed across have to be available > to restore. The next problem, in an imaginable worst case, is trying to restore (or better: recover) information from damaged media. > People have to remember, backup speed is not the > critical point of backups (you have to figure out a good schedule to get > everything done but that's it.) it's restore that is critical. That's why I backup to /dev/null, it's super fast! :-) > The > backup vendors want you to believe the opposite as their restore speed > tends to be abysmal. They also come up with funny concepts like cartridges that contain disks, but cannot be accessed in a standardized manner, so you'll have to work with the "drive" (which is more like a disk bay) to access the data. > Oh, backuppc is free. What you save on Backup exec licensing will pay > for your array. ;-) Allow me to add this: Avoid proprietary solutions. They will fail, and you're lost. Consider using only those parts that are common, standardized, and documented. For software, use open-source software. For disks, use those with a normal and available connector, for example SATA. Pay attention not to require something that depends on the "good will" of a profit-oriented corporation that will surprisingly cancel a service, introduce new fees, or discontinue the product. Do not believe in advertising. Check the facts yourself. Especially do the math. What does licensing cost? How long will licenses last? Are service contracts included, are they worth their money or just a means of "empty my pockets"? Do you require encryption? Who (except you) has the keys? Can you do the work, or is a "certified consultant" required, and at which (often continuous) cost? And test things, if possible. No, really: Test your setup. Randomly pull a disk, try a restore, compare source and backup. Pull another disk, or pull out the power cord. If your solution works, all relevant data will survive, and you have done good work. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...