[Leaplist] burn dvd backup

Bryan J. Smith b.j.smith at ieee.org
Sun Oct 12 12:07:16 EDT 2008


Ingo Claro wrote:  
> What do you mean by "pre-selected"?

I was curious why you were limiting your off-line media choices to DVD?

Ingo Claro wrote:  
> The backup is done daily to another server,

So you're doing a "near-line" backup to another server.  Good.
Now how are you managing those?  Their rotation?  Etc...?

One thing I highly recommend is the use of LVM (LVM2-DM in the case of
2.6) for snapshots on both the data and backup servers (your backup
server could be another data server too).  That way you can reference
times/states of the systems of each.  I.e., everytime you go to backup,
you snap the current state on both, then copy from the data to backup
server, and you now have date-based state of each filesystem (and
changes between), removing the need for multiple copies
on-line/near-line.

Ingo Claro wrote:  
> the DVD backup would be monthly, just in case the backup and the
> production server goes down.

Can you really make that feasible, given how much you're backing up and
the necessity for spanning multiple volumes?  The error rate of optical
is not very good (but that's another story).

Ingo Claro wrote: 
> have you any examples I can look at?

Most of my scripts are not very "simple."  ;)

My long-standing, generic "back2cd" (also works for DVDs, anything that
can be mastered by mkisofs) doesn't do multiple volumes.  It's very old
and only for "point backups" by users who are going to master under
10GiB of data.

I have written scripts around "afio", but I recommend you don't just
read them, but actually play with the tool yourself.  Why?  You have to
understand how to actually "restore".  The "afio" program works like
"cpio", only it does "standalone" multi-volume (given a size, won't
create a file bigger than X, and that file will be "standalone" so you
don't need the others), per-file compression (compresses files into the
archive, instead of the entire archive -- the latter is horrendous for
multi-volume), etc...

Mondo Rescue used to (still does?) use afio, because of its standalone
nature:  
  http://www.mondorescue.org/  

Mondo Rescue has a sister utility called Mindi Boot which is designed to
create a bootable CD/DVD to get your systems booting again (great from a
disaster recovery standpoint).  Ideally you should have a bootable
recovery disk for every system you need to restore, and a customized one
isn't a bad idea for select, core servers.

Ingo Claro wrote:  
> thanks fot the advice.

I really like 2.5" drive for backup at this point (and even as an
internal 3.5" drive replacement now).

I still use 16-22x DVD-R (in legacy cdrecord "Disc/Session at Once",
DaO/SaO, modes for maximum compatibility and longevity on a
non-Sony/Philips, non-DVD-RW drive, long story) for read-only media and
DVD-RAM (does read-after-write verify, and at today's 12x, it's like
having 7x equivalent, which is really no "slower" than 8x DVD+RW or 6x
DVD-RW) for read-write.  But 2.5" drive far more flexible and easier for
recovery.

I don't rely on 2.5" drives or DVD-R for more than 3-5 years retention,
and am more likely to use 2.5" drives in heavy retention of 12-18
months.  For longer-term, such as 10-15 years, I use LTO and DVD-RAM,
respectively.  Beyond that, given the growth of storage, you should
always try to keep all prior, legacy data on-line/near-line, and focus
on backing that up (not off-lining it).


Steve Litt wrote:  
> This doesn't directly answer your question, but if you have a second
> Linux box, you could use that second box as a backup server, rsh all
> changes to the backup server, and burn your DVDs from there. You get
> lightning quick backups, every backup is both incremental and full,
> and you can burn on a non-used box while using the heck out of your
> daily driver. See this...
> http://www.troubleshooters.cxm/lpm/200609/200609.htm

Steve Litt wrote:  
> :s/rsh/rsync/

Ingo Claro wrote: 
> thanks steve, I allready do that (rsync to another server). The burn to
> dvd is the missing step :)
> I got no X on that machine, so I must use command line.

I can't answer for Steve, but what I see him driving at, as I did as
well, is a result of you just coming in and saying "I need to backup to
DVD."  We're trying to figure out your "disaster recovery" strategy.
That's why we're mentioning "near-line" backup concepts like rsync to
another server, in addition to your pre-selected use of DVD as an
off-line mechanism.

Steve has pointed out that you shouldn't be off-lining to DVD from your
data server (main server), but the system you're rsyncing to (backup or
lesser used server).  This on-line -> near-line -> off-line strategy,
which _never_ has you go directly from on-line -> off-line storage, is
pretty much an industry "best practice" for the last five (5) years.

So what we're driving at is the "bigger picture" in backup/disaster
recovery.  You have a "main server" (on-line storage) that you rsync to
a "lesser server" (near-line storage for the "main server," even if it
has its own "on-line" storage for its own services too).  Now you should
master DVDs and record them on that "lesser server" (near-line storage).

In all honestly, I'd really recommend you look further at 2.5" discs if
you're already talking multi-volume DVD backups.  Even if you had
25GB/side BluRay, that's not going to be sustainable.  ;)


Steve Litt wrote:  
> Has anyone tried piping tar into mkisofs into cdrecord? I've never
> tried it, but if it worked that would be a cool way to record without
> an intermediate file.

The problem is that mkisofs isn't streamed.  It can't be.  Why?  It does
"multiple passes," largely for renaming to ISO9660 8.3 or 32 characters
(depending on mode, legacy or full), translations, etc...

I know Hugo (Mondo Rescue) started doing direct data to cdrecord type
operations, but I quickly pointed out the endianness/portability
nightmares of doing so.  I don't know what he's doing now.

Steve Litt wrote:  
> Or, perhaps could you spend $72.00 for an 8GB flash drive and put the 
> intermediate file(s) there?

Heck, $72 will get you a lot more in flash these days -- 16GB, maybe
even 32GB soon or after rebate.

Of course, it will also get you a _faster_ (write-wise than commodity
EEPROM technology) 250-320GB 2.5" SATA drive of 5200rpm maybe even
7200rpm spindle.  ;)


Ingo Claro wrote: 
> I could have 1 intermediate file, what I meat is if the backup would
> take more than 1 DVD, it would be ideal not to have all the files
> created in the HD prior to burning.

It's impossible to write once CD/DVD/optical.  You must pre-master.
Whether you do that in a "file" via mkisofs, or the OS "buffers" it
in /tmp or /var via another mechanism until you "commit," it's
impossible.

As I hinted to before, if you're worried about this, then you haven't
planned your storage correctly.  At least 25-50% of your storage should
be dedicated to snapshots, temporary copies (cache/spool/etc...) and
other functions.  If not, then you need more storage on-line.

That's why I prefer read-write media.  That's why I use 2.5" disc and,
to a far lesser extent now, DVD-RAM.  I only use read-only DVD-R on
end-user systems.

E.g., the user "masters" their own little "backup" CD using my legacy
script (back2cd) to their own, local system (and doesn't put anything on
the server), even if they are reading files from the server (such as
over a NFS mount).  They master the .ISO file locally and record locally
(never do anything on the server but access files).

As Steve also pointed out, don't master or do anything on the server (or
at least "main server").  I never even off-line data from the server.  I
always sync to a backup server (which can be another data server, but
"less important") and then off-line to 2.5", DVD-RAM, LTO, etc... there.



-- 
Bryan J  Smith              Professional, Technical Annoyance
mailto:b.j.smith at ieee.org  http://www.linkedin.com/in/bjsmith
-------------------------------------------------------------
           Fission Power:  An Inconvenient Solution


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the Leaplist mailing list