Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Dec 2014 06:13:40 +0100
From:      Polytropon <freebsd@edvax.de>
To:        Paul Pathiakis <pathiaki2@yahoo.com>
Cc:        freebsd-questions@freebsd.org
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141204061340.60bc8325.freebsd>