[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sheflug] Tape drive - backing up software?




A note for the future: can you get your mailer to force lines to be no more 
than about 76 chars[1]? It's leaving them long meaning I'm having to 
manually reformat them :)


> cheers! i managed to write my home direcotry to it just now, which 
> was cool. kinda leaves me wanting a graphical interface though; ive 
> downloaded amanda and going to check that out tmrw morning, and i've 
> tried KBackup but it keeps telling me my tape drive rewinds itself 
> (even if i tell it to use dev/nst0) and is therefore incompatible. i've
> tried the commman dump, but it isnt even found on my system (huh? i
> thought it was a standard linux thang)...

Dump isn't, no. It's standard on UNIX but it's one that people don't have 
much call for on Linux for some reason (probably another utility classed as 
"outdated"), but it is available on Sourceforge.

> i guess i should be more specific; actually what i want to do *is* 
> back up an entire hard disk - i have two disks one to run the system
> on and one purely for data (umm, mp3s). Its 20gb and I want to be able
> to just copy everyting from that disk onto tapes, though ofcourse i 
> guess itll have to be more than one since the largest this drive'll
> handle is 4gb compressed. 

Fairy nuff - dump or tar :) To dump a filesystem, either unmount it or if 
it is mounted, mount it read-only - this ensures nothing can modify the 
file system whilst the dump is proceeding. Dump does about 4 or 5 passes (I 
can't remember exactly - been a while since I last took a dump[2]), each 
pass does different things - and it has a different pass for directories 
and files - hence the read-only. You don't want directories to be 
created/go missing between passes. I don't know what happens if that 
happened - I've never tried :)

So in short:
	dump -0uaf /dev/st0 <partition>

eg,
	dump -0uaf /dev/st0 /dev/hda5

Flags are:
	0 - do a level 0 dump...ie, dump everything on the partition to
		tape. dump is clever in that in can do incremental backups
		using different dump levels. Reading the manpage is useful :)
		I tend only to do level 0 dumps as they're long term storage
		backups.
	u - Update /etc/dumpdates - this keeps a track of when each partition
		was last dumped.
	a - Write until end-of-media. dump historically had to be told the 
		length of the tape and the bpi. You can still do this with
		dump, but "-a" is more reliable. By default, dump assumes
		a 2300ft tape, with a density of 1600bpi. Don't even think
		or using the "-c" option which tells dump to "assume defaults
		for a cartridge tape" as these defaults are for 20 year old
		cartridge tapes - not 4mm DAT :)
	f - Output file

Restorations a little more complex. A full restoration requires (the 
following cookbook will assume that /dev/hda5, aka /usr/local, has failed 
and needs restoring:

	init s				Take system to single user
	umount /usr/local		Unmount the file system
	mke2fs /dev/hda5		Create a clean filesystem
	mount /dev/hda5 /usr/local	Mount the partition
	cd /usr/local			Change to it
	restore -f /dev/st0		Restores the backup
	init <x>			Go back to previous runlevel.

Now: I took the system to single user as I didn't want anyone or anything 
trying to access the filesystem during a restore. So this kills all the 
users and any process that may try and use the filesystem. However, the 
need to do this varies on the situation, so you may never need to switch 
filesystems. A dump should always be restored on a fresh filesystem - this 
is a good to do anyway as it means you won't have any old crud lying about. 
It also allows you to exercise the filesystem to check it for errors before 
restoring.

You can have an "interactive restore". To do this:
	restore -if /dev/st0
this gives you a command prompt, and you can browse the tape (cd, ls), put 
files into a restore list as you want them and then run the restore. Again, 
read the manpage.

A final note: I don't know if there are any front ends for dump and 
restore. :)

> The drive is a DDS-1 hp surestore, im not sure if that clears up 
> the compressin thing. also, im not sure about the whole hardware / 
> software compression issue... does my tape drive automatically 
> compress data? i wouldve assumed i had to do that through a program
> before writing it to the drive...

If a drive has hardware compression it will do it automatically :) If you 
aren't sure, kick off a tar from the root directory and see how far the 
backup gets :) [tar cvf /dev/st0 /]. However a quick search on Google has 
found that according to http://www.microware.com.hk/mul/hp/tape5000.htm, 
the drive is a DDS-DC, so could handle up to 4GB on a standard DDS 
cartridge.

If you have the software to the compression, this will essentially negate 
the effects of any hardware compression (try compressing data that's 
already compressed - it don't work), so leave it to the hardware. It's more 
likely to compress more as well as be higher performance (as it's all done 
in hardware).

Chris...
[1] though saying that, I've seen one email I've sent have a couple of 
unformatted paragraphs, so I'll keep an eye out and see if this does 
similar, then investigate further.
[2] No cheap jokes, thanks. :)


-- 
\ Chris Johnson           \  "If not for me then, do it for yourself. If not
 \ cej [at] nccnet.co.uk        \  for then do it for the world." -- Stevie Nicks
  \ www.nccnet.co.uk/~cej/  ~-----------------------------------------+
   \ Redclaw chat - http://redclaw.org.uk - telnet redclaw.org.uk 2000 \____


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.