SUMMARY: Resuming tar restore

From: Filipe Litaiff <>
Date: Mon Apr 19 2004 - 10:49:23 EDT
Greetings Forumers,

This is not quite an summary. We weren't able to test the solutions provided,
but I think there is some information that deserves to be shared.

1 - One solution would be using exclude or include files for tar (-I and -X
options). It doesn4t help us, mostly because the tape have to be read anyway
(time consuming) to find the 'file headers' tar writes on the archive at the
beggining of every file.

2 - If you are trying to extract some files from a tepe with a big archive,
and you are time constrained, the option suggested  on the tar man page to
extract archives based no regular expressions is a no-brainer. It executes tar

"Filename substitution  wildcards  cannot  be  used  for extracting files
the archive. Rather, use a command  of  the form:

     tar xvf ... /dev/rmt/0 `tar tf ... /dev/rmt/0 | \
          grep 'pattern' `
Well, it should work nicely with disk archives.

3 - The only way one could extract files from any given point on the archive
would be:

	3.1: Find the block size. Do the following:
		"dd if=TAPEDRIVE of=/tmp/tape.block count=1 bs=128k
		where the 'bs=128k' is some arbitrarily large value -- maybe 256k
		-- it is needed to pre-establish a buffer size for dd.
		Then 'ls -l /tmp/tape.block' and see how big the file is -- that's
		your tape block size."
		Thanks Bill R. Williams for the procedure.

	3.2: Forward to any point right before the first file you want to download.
		- Considering the block size you found in the last procedure is the record
the mt man page
		 referes to, and you know how much in kbytes the tape should be forwarded to
find the spot, do the following:

		mt -f <drive> fsr <nrecords>
		<nrecords>=<the amount in kbytes you estimate you have to forward> / <block
size in kbytes>
		<drive>=non-rewindable tape device.

	3.3: Use GNU tar to try to extract the files from that point. The POSIX tar
provided with Solaris can't do this.
		You'll probably see something like this:

		ficus# /usr/local/bin/tar -xvf /dev/rmt/0cn
		Blocksize = 126 records
		Hmm, this doesn't look like a tar archive.
		Skipping to next file header...

		drwxr-xr-x root/other  Jul 27 09:51 1999 /
		drwxr-xr-x root/sys    Jul 27 07:36 1999 /etc/
		drwxrwxr-x root/sys    Mar  8 14:27 1999 /etc/default/
		-r--r--r-- root/sys  Oct 30 16:58 1996 /etc/default/sys-suspend
		-r-xr-xr-x bin/bin    Mar  5 12:45 1999 /etc/default/cron
		-r--r--r-- bin/bin    Mar  5 12:45 1999 /etc/default/fs

NOTE: I haven't tried this. I'm not sure even if the record thing mt uses is
actually the size you get using the 3.1 procedure. If you are willing to use
this, please double-check every information provided.

Thanks to:

Darren Dunham
Bill R. Williams
Terry L Moore
Anatoliy Lisovskiy


Filipe Litaiff

-----Original Message-----
From: Filipe Litaiff
Sent: Thursday, April 15, 2004 3:20 PM
Subject: Resuming tar restore

Hi Forumers,

We were restoring a very big tar archive from tape when something broke the
command and the restore was interrupted.

If we restart the tar we4ll take too long to restore files we already have

We know where the tar was broken. What we want to figure out a way to resume
the extraction, from given file to the end of the archive.

Since restoring it from the beggining is not a good option, and the tar man
page doesn4t help much, what could we do?

We have a list of the remaining files that are still on the archive. Would it

The tar man page states something that might help, but I think it4ll have
lousy restore times since it runs tar twice:

"Filename substitution  wildcards  cannot  be  used  for extracting files
the archive. Rather, use a command  of  the form:

     tar xvf ... /dev/rmt/0 `tar tf ... /dev/rmt/0 | \
          grep 'pattern' `

Any help would be appreciated.

Thanks in advance,

sunmanagers mailing list
sunmanagers mailing list
Received on Mon Apr 19 10:49:15 2004

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:31 EST