fbackup and cpio

[Fred Martin_1]

I've been using cpio with a DLT tape for years but am now planning on switching to fbackup.

A few questions...

For my cpio routine, I created a file list, piped it to cpio, then after the backup was finished, I read the file list back from the tape to another file, and compared the two lists. Any diff between the two lists was emailed to me. That was my 'verify' operation.

It appears that fbackup has a better facility for warnings and errors.

Is it necessary for me to read back the tape and compare, as I did before, or can I rely on the return code from fbackup?

Also, fbackup issues warnings about sockets and does not back them up. cpio did the same thing. Should I ignore that? I don't have any bootable tapes or other system backup.

Fred

[James R. Ferguson · Accepted solution]

Hi Fred:

I happen to really like 'fbackup' and 'frecover' although they are HP-proprietary tools and therefore not portable. Unfortunately, sometime after 11.31 these tools will not be supported for the creation of new archives. Instead, 'pax' archives are recommended.

The manpages for both 'fbackup' and 'frecover' actually provide a good overview of the inherent features of these tools.

One of the many elements of 'fbackup' I like is that a file that has changed on disk during the time it is being copied will be marked "bad" on the tape and a retry of the copy attempted up to 'maxretries' times. Such "bad" files cannot be recovered.

You will be warned of such retries and this does cause the overall return code from 'fbackup' to be non-zero (actually = 4). For this reason I prefer to write verbose messages from an 'fbackup' session to a temporary file. At the end of the session, I parse the file looking for warnings that I either want to take action on or ignore.

As for sockets, these are transient communication points for which a backup would have no rationale.

You *must* use Ignite to create a bootable, recovery image of vg00. 'fbackup' is NOT a substitute.

Regards!

...JRF...

[Fred Martin_1]

Thanks James.

It appears that I can rely on a verbose output of fbackup, and assume that the backup is good, if there are no errors or warnings that I care about.

frecover, on the other hand, has the -I and -N options which would allow me to verify the tape contents.

I'll probably take the latter route, for safety. As it is now, I do that with cpio and it takes hours, but fbackup is quicker than cpio in my case anyway, so I'm still better off.

About Ignite: I tried to fire that up to make a bootable image some time ago, but got lots of errors. I'll try again soon and maybe open a thread here about it. I would like to get that going.

[Fred Martin_1]

This produces no output:

# frecover -I -v -f $TAPE

But this produces a file listing:

# frecover -I - -f $TAPE

Not sure of the significance of the '-' by itself, man frecover doesn't mention it, and not sure why the -v doesn't work.

Fred

[Fred Martin_1]

Ah, ok, I think it should be...

# frecover -I - -v -f $TAPE

The '-' refers to the default output and is the path for -I.

Fred

[James R. Ferguson]

Hi Fred:

> Not sure of the significance of the '-' by itself

The dash ('-') as an argument means STDOUT when used with '-I'. In general, a dash as an argument means STDIN when a file descriptor is used for input; or STDOUT when a file descriptor used for output.

Regards!

...JRF...

[Fred Martin_1]

Just a point of interest but I can't seem to redirect STDOUT:

# frecover -I - -f $TAPE 1>/tmp/outfile

This works:

# frecover -I /tmp/outfile -f $TAPE

But shouldn't they be equivalent?

[Fred Martin_1]

I'm trying to use fbackup and relative pathnames, i.e. the graph contains:

i ./home

And I 'cd' to / before running fbackup.

But, I'm looking at man frecovery and it appears that the -X switch will allow recovery to someplace other than the absolute path anyway.

man fbackup says normally files are stored with absolute pathnames but my graph file seems to produce an frecover -I listing that shows them as relative, anyway.

Should I give up and change the graph to the absolute path, and then rely on frecover -X?

Fred

[A. Clay Stephenson]

That's one of those "six of one; half-a-dozen of the other" questions. The bad thing about absolute paths is also the good thing --- files go right back where they came from and -X does give you the power to alter the destination. Nevertheless, whenever possible I tend to use relative paths for everything. Now if your backup uses relative paths and does cd to / to begin then you better make certain that you test that cd before starting the backup or you could wind up with a very small backup. Of course, if you can't cd to / then you probably have other things to worry about as well.

Fbackup/frecover is powerful and free but I would really start looking at some other answers such as Data Protector so that you can do all your UNIX, Windows, Novell, ... backups in one environment and even mix the backups as well.

[James R. Ferguson]

Hi Fred:

While you can use 'fbackup' and a graph with relative path names, 'frecover' as you stated allows you to recover to a current directory without "much ado...".

In my opinion this is more obvious some time later if/when you proceed to actually restore something. That is, you don't rely on a cursory inspection of the graph file to determine that relative paths were employed, but rather always use absolute ones and explicitly (pun intended) use the '-X' option of 'frecover' to place the recovered files in a relative location.

Regards!

...JRF...