DynamicDuo Devblog

restore of Tower of Hanoi Backups from dump

Status: Unix

I just suffered through figuring out how to restore the daily backups I make using a shell script I wrote to use dump to make backups in the tower of hanoi sequence. Yes, I know, I should already have had this figured out, but not having done so was probably due to the same stupidity that caused my pinky finger to twitch before I finished typing the command I wanted to type and sending:

rm -rf /home/cvs/

to the system, deleting all my precious cvs repositories. (I was trying to delete one so that I could rebuild it, and certainly didn't want to delete all of them).

This How-To has already done a nice job of explaining a bit about how the tower of hanoi sequence works, so I won't go into it here. I found the restore command extremely hard to grok, due to a few misunderstandings and some bad (IMHO) quidance in the tool.

The first thing that I was unsure about was what order I should restore my backups in. You should restore the older backups first, as the more recent backups update the older ones.

One of the biggest sources of confusion for me was that the dump/restore combo were originally written for tape backups and allow you to span large backups over multiple tabe volumes. I misread guidance about volumes in multiple places to be talking about different incremental backups. I had it in my head that I should run the restore command once, and then feed the different incremental backups in one by one, but that is not the case.

It is hard to explain all the different things I tried without going through them again and pasting the results here, and I need to get back to some other work, so quickly here is a summary of my restore process.

My most recent backup was from about 1A.M. Saturday morning. I have a weekly backup cycle with dump levels as follows:

Sun - 0
Mon - 3
Tue - 2
Wed - 5
Thu - 4
Fri - 7
Sat - 6

This means that I need to restore my backups in the order: Sun > Tue > Thu > Sat (read the howto above if that isn't clear to you) I kept trying to do this all inside one restore session, but that isn't how it works. Here was the process that finally did work:

mkdir ~/restore
cd ~/restore
restore -iv -f /backup/home.dump0

^^^ This contains Sundays full backup of the /home directory

restore > add cvs

^^^ at this point a whole bunch of Make node lines scroll by

restore > extract
Extract requested files
You have not read any tapes yet.
If you are extracting just a few files, start with the last volume
and work towards the first; restore can quickly skip tapes that
have no further files to extract. Otherwise, begin with volume 1.
Specify next volume #: 

^^^ here we enter 1 and a whole bunch of files are extracted to ~/restore/cvs

set owner/mode for '.'? [yn] y
restore > quit
restore -iv -f /backup/home.dump2
restore -iv -f /backup/home.dump4
restore -iv -f /backup/home.dump6

^^^ we repeat the extract process in these restore sessions exactly as we did with the full backup, but this time it will probably write a lot less.

mv /home/cvs /home/cvs.bak
mv ~/restore/cvs /home
rmdir ~/restore

And we're done. Note for myself, be sure to use the write paths for the backup files or else none of this will work.

CVS Branching

Status: cvs

Branching

A good way to do branching in CVS is to make a branch at every release and continue the main development on the trunk. Changes on the release branch that also need to be applied to the trunk can be merged back into the trunk from the branch. Having the branch will allow you to have an active working copy of the release version and continue making corrections to it without worrying about messing up the active development version and without applying every change you made in two places manually.

For an example of how to create a branch based on a release version we’ll use a revision tagged release_0630 for the head of the branch.

##$ ls
website/
##$ cvs co -d website0630 -r release_0630 website
U a whole bunch
U of stuff
##$ ls
website/ website0630/
##$ cd website0630
##$ cvs tag -b Release_0630-branch
T a whole bunch
T of stuff
##$

Branch tags are easy to confuse with other tags, so it may be a good idea to include the word branch in the tagname of a branch.

Now to actually check out that working copy as a working copy on the branch:

##$ cd ..
##$ mv website0630 website0630.bak
##$ cvs co -d website0630 -r Release_0630-branch website

(You can also change the working copy to a copy of that branch with an update command [ cvs up -r Release_0630-branch ] but be careful not to do this if you have made changes to any of the files in the working copy as it could create problems or unexpected changes to your data)

Like always, if you want to revert the working copy to the latest version on the trunk you need to clear the sticky tags:

##$ cvs up -A -d
(the -d option to up builds directories like co does)

Merging Branch to Trunk

first lets get back to the latest version on the trunk:

##$ cd ../website
##$ cvs up

Now we’ll check for differences between the trunk and the branch

##$ cvs -q diff -c -r Release_0630-branch
(the -c option to diff is for a context diff, -u is also nice)

Now we’ll pretend that we found some differences in the branch that need to be checked into the trunk

##$ cvs up -d -j Release_0630-branch
the -j option means join

Sometimes a branch will continue to be actively developed even after the trunk has undergone a merge from it. For example, this can happen if a second bug in the previous public release is discovered and has to be fixed on the branch.

If you try to merge those changes with that same command you’ll get conflicts.

What we’ll want to do to make it easiest to avoid this is to tag the branch whenever we merge changes. This way we can use the tag from the last merge as the starting point for the join.

Let’s take a look at a scenario where we’ve done this properly:

##$ pwd
website/ website0630/
##$ cd website
##$ cvs up
##$ cvs up -d -j Release_0630-branch
##$ cd ../website0630
##$ cvs up
##$ cvs tag Merge_Release0630_0708

After merging we tagged the branch, so now on July 10th when we want to merge again we can do it like this:

##$ cd ../website
##$ cvs up
##$ cvs up -d -j Merge_Release0630_0708 -j Release_0630-branch
##$ cd ../website0630
##$ cvs tag Merge_Release0630_0710

Those two -j options told it to start at the revision marked and proceed to the latest revision in the branch when determining what to merge with the trunk.

I included the branch name in the tag for merging because tag names must be unique per file, even across multiple branches. If we merged two seperate branches into the trunk on the same day it would be really easy to have problems with duplicate tag names. Adding the branch name solves that particular problem.

Advanced tips

rtag

It is not really necessary to check out a working copy at the branch point in order to create the branch. We could have used rtags since we now the tag name of the release point:

##$ cvs rtag -b -r release_0630 Release_0630-branch website

Additional Helpful Tips

To get a list of tags in the repository you can use cvs log. Here’s an example:

##$ cvs log index.html
Working file: index.html
head: 1.4
branch:
locks: strict
access list:
symbolic names:
Release_0630: 1.4
start: 1.1.1.1
akatombo: 1.1.1
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
----------------------------
revision 1.4
date: 2005/06/16 14:01:03; author: bob; state: Exp; lines: +150 -150
giant Japanese checkin
...

As you can see above, the symbolic names section contains a list of the tags on that file, and which revision number they are tied to

Printing man pages to other formats

Status: lurnin'

Is there a good way to print a man page to some other format like html or pdf?
for example, to make a .pdf file for the ls man page:
zcat /usr/share/man/man1/ls.1 | groff -man -Tps | ps2pdf - /tmp/ls.pdf
for html: zcat /usr/share/man/man1/ls.1 | groff -man -Thtml > /tmp/ls.html
the pdf will probably print nicer
oh great thanks!
does that work with manpage.8.gz?
looks like it

trackback test

Status: lurnin'

This is a test of trackbacks to the Akatombo Media site to see if some setting changes have made a difference that will help stem the tide of trackback spam I get.

BZipping Directories using Tar

Status: lurnin'

Just a quick note before I forget on how to run bzip2 and compress a directory structure using the tar utility. Actually what it really does is pass the directory structure through tar to bzip2 which compresses it and writes it to a file.

tar -cf - dir | bzip2 -c9 > /destination/path/filename.tar.bz2

the '-' tells tar to write to stdout (so instead of writing to the disk, it writes to the pipe (|)

then bzip2 takes the input, compresses it, and writes it to stdout again (that is what the -c parameter does).

The shell sees > and redirects all of the output into the file specified.

Nothing hits the disk until '>'

Final Notes: the 9 parameter to the bzip2 file tells it to compress it as much as possible. This is up to you, 0 is the least CPU intensive and lowest compression, while 9 is the most CPU intensive and gives the highest compression.

testing trackbacks in ee

Status:

We'll see if this trackback test works.

Trackback errors in MT and how to fix them

Status: Just a Comment

Was just working trying to trackback to test trackbacks on another site, and noticed that I was getting an error. A look at the activity log showed the following:

Ping '

TRACKBACK URL

' failed: HTTP error: 500 Can't locate HTML/HeadParser.pm in @INC (@INC contains:

SOME PATHS

A little research showed that I needed but didn't have the libwww perl library which contains the HeadParser.pm perl module

Since I am on a FreeBSD system it was a simple matter of installing the port:

portinstall -v p5-libwww