[H-GEN] Linux Backup

Robert Brockway robert at timetraveller.org
Fri May 9 12:57:48 EDT 2003


[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On Fri, 9 May 2003, Jason Parker-Burlingham wrote:

> > With an uncompressed backup you risk losing one file.
>
> Well, hang on a minute.  Do you mean one "file" on the tape, or one
> file as it would exist on the filesystem?  If we're talking about

i was talking about one file as it would exist on the filesystem.

> dump, then surely a tape error would tend to invalidate the entire
> dump output, making all the files contained it after the error
> unretrievable?  So, then, how does one increase one's risk by
> compressing dump output before sending it to tape?

If you suffer an error reading from an uncompressed dump on tape, you
won't lose the rest of the dump.  I've had this happen with ufsdump
under Solaris.  I didn't lose the rest of the files.  Dump
stores each file seperately, referencing them by inode so it knows
when individual files in the dump begin & end.

> I think they're the only tenable solution for backups of large amounts
> of data.

Possibly.  This is certainly the feeling among many admins.  I've never
played with really high end tape technologies so I don't know if they
suffer the same limitations as low end technologies.

I suspect that where ever a tape technology can be applied, a disk
technology can be applied also (63 HDs on a firewire bus anyone?).
Bandwidth would be an issue but it is in tape technologies too. By the
time we're talking about the storage capacity of 63 drives (6.300Tb, say)
we're talking about the world's largest tape backup systems.  Any
evaluation has to be made in that context.  I could envision a rack with
63 HDs doing backups that can be wheeled into a fireproof safe or offsite,
or even have its drives removed quite easily.  The equivalent tape backup
systems don't move at all and need to have their tapes removed for offsite
storage.  The largest tape backup system I've ever seen is about 5 metres
across, and has hundreds of DLT tapes inside.  A huge mechanicl arm loads
& unloads tapes.

I really feel that disk backups are viable in many cases and are not
getting the air time they deserve.

> For home users---this being HUMBUG after all---you're probably right.

At this stage I'm aiming the idea at home users & small businesses, who
often have a similar amount of data to backup.

> I am thinking of getting myself an IDE CD writer for making backups
> (although I'll probably need a larger disk to hold the dumps).

CD's didn't cut it for me.  I wanted something that would store all my
data & allow easy retrieval in an emergency.  There is a difference
between a backup strategy & a DR (disaster recovery) strategy afterall. I
know Jason knows this, but I think it is worth reiterating for the wider
community.

Writable DVDs were getting better at 4Gb.  They still fell short of my
backup needs and were more than 3 times the price of my solution when I
set it up. Today the price as dropped but they still lag in capacity by
more than an order of magnitude (and falling further behind all the time).

Backing up to multiple CDs or DVDs isn't viable as it is a pain to have to
swap media, especially since backups often occur overnight.

> > Getting back to compression, there is a middle path here - the zip utility
> > compresses each file individually before archiving.
>
> I see now.  You are talking about writing tar format backups to tape.

And dump.  Same rules apply.

Cheers,
	Rob

-- 
Robert Brockway B.Sc. email: robert at timetraveller.org  ICQ: 104781119
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/



More information about the General mailing list