Restore OBSD Over SSH

[revzalot]

I've been dumping my backups locally on a separate drive making restore a cinch. But now I need that drive space for mail so I'm forced to dump backups over ssh. I want to learn how to restore openbsd over ssh. Yes I know how to prepare the new openbsd server using makedev, newfs, and mount. I just need to know the steps and the unix script to restore the partition from the remote server via ssh. No I don't want to rely on other software like bacula, amanda, etc.

[jggimi]

On a secure network:

1. Boot bsd.rd
2. Recreate MBR
3. Recreate Disklabel
4. Start network

For each filesystem:

1. newfs(8)
2. mount(8)
3. cd(1) into filesystem
4. make a temp directory for restore (/tmp isn't big enough)
5. set TMPDIR to point to that temp directory
6. Pipe backup file into restore(8)
7. remove the temp directory and the restoresymtable file in the top level directory.

On an insecure network, you need SSH, which is not included in bsd.rd. Either install the OS and reboot before restoring, or use live media.

[jggimi]

Here's an example of a restore on a secure network, using ftp(1) to pipe the compressed dump data over the network and uncompress it before piping it into restore(8), Note: ftp transmits everything, including userid/password, without encryption.

# ftp -o - ftp://user@server/backup.file.gz | gunzip | restore -rf -

Here's an example using SSH to pipe the compressed dump data over the network and uncompress it before piping it into restore(8) on an insecure network. The OS must be installed already.

# ssh user@system "cat backup.file.gz" | gunzip | restore -rf -

[s2scott]

Originally Posted by jggimi

...The OS must be installed already.

Nice, potent little command suite!

I once saw a variant of this most-excellent approach that used an ultra-skinny bootable USB fob, then similar over-the-secured-net command sequences to effect a bare drive restore (whole system).

I'll see if I can dig it out.

/S

[jggimi]

I noticed a typo, so I've corrected it, above.

[s2scott]

/S

[revzalot]

Excellent jggimi!

[revzalot]

On a secure network:

1. Boot bsd.rd

bsd.rd
boot

2. Recreate MBR

fdisk -iy wd0

3. Recreate Disklabel

disklabel -E wd0

4. Start networkOn a secure network:

ifconfig xl0 192.168.0.4 netmask 255.255.255.0

1. newfs(8)
newfs wd0a

2. mount(8)

mount /dev/wd0a /mnt

3. cd(1) into filesystem

cd /mnt

4. make a temp directory for restore (/tmp isn't big enough)


mkdir /mnt/temp

5. set TMPDIR to point to that temp directory

export TMPDIR=/mnt/temp

6. Pipe backup file into restore(8)

# ftp -o - ftp://user@server/backup.file.gz | gunzip | restore -rf -

7. remove the temp directory and the restoresymtable file in the top level directory.

rm -rf /mnt/temp

8. Finally make the root drive bootable

cp /usr/mdec/boot /mnt/root
/usr/mdec/installboot -v /mnt/root /usr/mdec/biosboot wd0

[jggimi]

Originally Posted by revzalot

rm -rf /mnt/temp

# rm -rf /mnt/{restoresymtable,temp}

[revzalot]

One more thing, after restoring all the partitions, do you apply the following to make it bootable?

cat /usr/mdec/boot >/mnt/root
/usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot wd0a

[jggimi]

Yes. Good catch.

You can cp(1) /usr/mdec/boot, no need to pipe it.
And, no need for the "a" on the end of wd0 for installboot, since it's writing to the PBR.

[revzalot]

One more concern, is gunzip readily available in bsd.rd?

[jggimi]

yes

[jggimi]

And while we're here, you can shorten the ifconfig(1) statement to:

# ifconfig xl0 192.168.0.4/24

[revzalot]

Ok one more scenario that popped up. I upgraded to -stable and did full level 0 dump on all my paritions but somehow my root.dmp file got erased mysteriously. Can I just install a new system, upgrade to -stable and finally restore all my dump files without the original root.dmp file?

[jggimi]

I don't understand your exact state. If you're just practicing, then dump your root partition again, or, recover it from /altroot if you use that.

A new system install will create an entire hierarchy, including /usr and /var. Depending on your specific filesystems that include OS-related files of all kinds, you could easily get out-of-sync without a great deal of care.

For example, packages usually place files in /usr/local and in /var, but they are not restricted to those, many put configuration files in /etc. In addition, the installed-package database is stored in /var/db/pkg/*, and needs to be kept in sync with /etc, /usr/local, and other /var components that packages create.

[revzalot]

Thanks again for the insights.