backing up to usb box?

N

NightTripper

I have found all kinds of backups to tape (anyone still using tape?). But I would like to backup my da0 to a usb drive. Is this posible? And will it make a perfect copy? One that I can restore and go from.

Mark
 
You can use whatever you like to store the backup. Tapes, external harddrives, memory sticks, writable CDs, you name it.
 
Script is a little out of date. I don't think it is for v9. When run it gave me a boatload of errors. Is this where it is having problems?
# bsdlabel -B -w da0s1
Should be
# bsdlabel -B -w da0p1

My df -h

Code: 
# df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/da0p2      4G    372M    3.3G    10%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/da0p5      4G    306M    3.3G     8%    /var
/dev/da0p6      2G     16M    1.8G     1%    /tmp
/dev/da0p7     92G    6.5G     78G     8%    /usr
zpool0         15G     31k     15G     0%    /zpool0
zpool1        399G     31k    399G     0%    /zpool1
/dev/md0       19M     24k     17M     0%    /tmp

The zpool's do not need to be backed up.
Code: 
#!/bin/sh
# This script will use dump command to backup your running
# system to a USB flash stick.
# This is run as root. 
#
# Change these device unit pre-fixs in the code below as needed
#     ad0 is the live file system
#     da0 is the target
#
# Comment or uncomment the 4 dump statements depending on 
# whether you want to compress the saved dump file.
#
# Be sure to unplug your USB stick and re-plug it in to
# mount it again. 

echo "  "
echo "  "
echo "Starting time for this live file system dump is"
date

echo "  "
echo "  "
echo "Prepare the target"
dd if=/dev/zero of=/dev/da0 count=4
fdisk -BI /dev/da0
bsdlabel -B -w da0s1
newfs -U /dev/da0s1a
mount /dev/da0s1a /mnt
cd /mnt

echo "  "
echo "  "
echo "Post the dump date"
date > date.of.dump
cat date.of.dump

echo "  "
echo "  "
echo "Post the MBR"
dd if=/dev/ad0 count=1 > MBR
#dd if=/dev/ad0 count=1 | od -c

echo "  "
echo "  "
echo "Collect live Slice Partition sizes and save"
bsdlabel ad0s1 > liveSPsizes
cat liveSPsizes

echo "  "
echo "  "
echo "Collect live file system sizes and save"
df -h  > liveFSsizes
cat liveFSsizes

echo "  "
echo "  "
echo "Post the fstab"
cp /etc/fstab > fstab
cat /etc/fstab

echo "  "
echo "  "
echo "Post the script used to create this dump"
cp /root/bin/fbsd2backup > fbsd2backup

echo "  "
echo "  "
echo "Post the script used to restore this dump"
cp /root/bin/fbsd2restore > fbsd2restore

echo "  "
echo "  "
echo "Dump file system 'a' / "
dump -0Lauf dump0-root /dev/ad0s1a 
#dump -0Lauf dump0-root /dev/ad0s1a | gzip 

echo "  "
echo "  "
echo "Dump file system 'd' /var "
dump -0Lauf dump0-var /dev/ad0s1d
#dump -0Lauf dump0-var /dev/ad0s1d | gzip

echo "  "
echo "  "
echo "Dump file system 'e' /tmp "
dump -0Lauf dump0-tmp /dev/ad0s1e
#dump -0Lauf dump0-tmp /dev/ad0s1e | gzip

echo "  "
echo "  "
echo "Dump file system 'f' /usr "
dump -0Lauf dump0-usr /dev/ad0s1f
#dump -0Lauf dump0-usr /dev/ad0s1f | gzip
sync
cd /root
umount /mnt


echo "  "
echo "  "
echo "Ending time for this live file system dump is"
date

echo "  "
echo "  "
echo "Script completed"
echo "  "
echo "  "
echo "Unplug your USB stick NOW"Disaster Recovery:
 
That should work just fine on FreeBSD 9 if you have an MBR partitioned disk with bsdlabel(8) partitioned slice on it. For GPT partitioned disk the script would need larger modifications.
 
I'm surprised running that script hasn't screwed up your system.
Judging by your df output, your live disk is da0 and gpt partitioned. The backup script is hard coded to backup to da0 and the first thing it does is try and wipe any existing partition table. I just hope one of the errors you got was the system complaining that you can't overwrite the mounted disk.

You first need to check what device the USB disk shows up as, which is probably da1.
The script then needs to be quite heavily modified to preferably gpart the USB disk rather than fdisk/bsdlabel. It should also dump the gpt table of the source disk, not the bsdlabel, as your primary is gpt.

I'm not sure if you really need to dump the boot sector but the ad0 device names need changing in all the dump commands to match what's in your df output (eg da0p2 instead of ad0s1a).

The script also tries to backup itself and the related restore script but assumes they are in /root/bin/fbsd2backup and /root/bin/fbsd2restore.
 
Well did but I re-installed again so I didn't notice anything.

I am trying to setup a NOAAport server. Very demanding with everything NOAA has being received by this server. And a pain to setup.

I would like to be able to get a base setup backed up so all I have to do is one click restore.

MArk
 
op never said what release of FreeBSD he was using. The included scripts are for a default hard drive config for 8.x and older releases. 9.0 used new format of a single slice with different boot strap config, so for sure op has to change it if using 9.0 and or zfs.
 
Oh ya I'm using 9 and zfs ;)

I average 4 fresh installs a day. But I think I am zeroing on a configuration that will work.

Mark
 
But it would be nice to have a restore like windows has. I made a restore disk for each of my kids. Plus two for me ;)

Mark
 
Partition Type Size Mountpoint Label
freebsd-boot 512K
freebsd-ufs 4G / exrootfs
freebsd-swap 16G exswap
freebsd-swap 16G exswap (will comment out in fstab.conf and use as a zfs spool disk
freebsd-ufs 4G /var exvarfs
freebsd-ufs 2G /tmp extmpfs
freebsd-ufs accept the default (remainder of the disk) /usr exusrfs
 
Why is every question I asked returned by a question?? This is very fustrating. No wounder people are put off by linux.

Mark
 
I've (a >> several )CLI for rsync > da0 (search the forums for bwlimit. I run ( it>>them ) in a .sh OR from stored history in various permutations (i.e. nothing I should post here, I've ten variants and you'd probably want an eleventh...). Also the restore (typically not "one" process but a sequence of processes, each of which may fail, so one should use multiple backup configurations...) is a whole other matter, depending upon the configurations/hardware you have already working.
 
Hi NightTripper,

Your question is very broad. Please have a think about these issues:

  1. Do you want to be able to "reincarnate" a lost system to its exact pre-breakage configuration; or
  2. Is it sufficient to have a copy of all the files so that the system can be pieced back together manually?
The approach for 1 requires more questions and answers regarding frequency, capacity, methods, time to recover, and testing. You will generally require a fair bit of storage capacity. It's much harder to do now, but easier in the recovery phase.

The approach for 2 can be as simple as running rsync(1) writing to the USB disk, with a suitable configuration for ssh(1). However rsnapshot(1) probably provides the best way to implement this strategy. It's real easy to implement, but harder if you ever actually have to recover.

[A really good place to start any backup strategy is to get printed copies of the output of the df(1) and mount(8) commands.]

Cheers,
 
My original question was for a total backup. In windows it is very easy to do. From all the reply's I get in here. It seems that you have to have a phd in scripting to get it done.

A little farther down the thread you will notice that I am reformatting and installing about four times a day trying to get things right. A total install would make things so much easier.

I'm not so sure now that the speed of the file system of BSD. Makes up for the steep learning curve.

Mark
 
The more choices, the more complicated it gets. FreeBSD gives lots of options.

If you want an end-user application that can back up FreeBSD, newer versions of Clonezilla understand UFS. It may also unnecessarily back up swap partitions.

Reinstalling to undo changes is not generally necessary with FreeBSD. You might be making things more difficult than needed.
 
night said:
My original question was for a total backup. In windows it is very easy to do. From all the reply's I get in here. It seems that you have to have a phd in scripting to get it done.

A little farther down the thread you will notice that I am reformatting and installing about four times a day trying to get things right. A total install would make things so much easier.

I'm not so sure now that the speed of the file system of BSD. Makes up for the steep learning curve.

Mark
Click to expand...

My backup mentioned above has restored multiple times (although with difficulty) from hard disk crashes to the next disk. It took a while to set up, but I can incrementally backup while I use the desktop normally in the background (no GUI.) That is why I've posted it elsewhere, so others do not have to spend about ten hours figuring it out.... OTOH
once it works, it is also easy to break (a misplaced path in the command, etc.) But IMHO the
more difficult the setup of the backup, the more reliable the restore, so it is advantageous in
the end to plan accordingly.
 
dd or its variants in ports; it consumes all of the i/o bandwidth and much of the CPU though usually, and may overtax a driver or chipset serving a usb disk or the bios on the disk itself, or even corrupt the filesystem on the usb disk or flashdrive by copying to it too rapidly. (Generally speaking; one may probably craft a workable solution with pipes or whatnot...); OTOH dump/restore is a more copy-data-only usual solution (that sometimes also may encounter the same problems as dd would... I've hosed enough filesystems on usb disks to only use the rysnc... bwlimit out of sheer convenience and reliability.
 
night said:
Is there no CMD that will backup a drive no matter what is on it?

Mark
Click to expand...

Hi Mark,

As intimated by jb_fvwm2, I think that dd(1) the right answer to the wrong question. The uses for dd as a backup tool are, at best, both limited and esoteric. It has some special uses, but is slow (mainly because it copies all data on disk, including unused blocks).

You seem to want "a restore disk just like windows has". FreeBSD does not have an exact replica of that.

Posts here have given many plausible ways to backup and recover your system (dump/restore, cpio, tar, ...).

They will all work. However, they generally require you to prepare a new boot disk by booting from CD (or DVD, thumb drive, network, ...) installing a boot block, and creating empty file systems prior to commencing restoration. This is the time honoured Unix way.

The post by fbsd1 was excellent introduction to dump/restore. This is a really good place to start, for no other reason that it is the classic backup and recovery method for nearly all modern Unix variants.

Another good option is to use rsync(1) and rsnapshot(1). Rsnapshot(1) can save you truckloads of disk space because it only stores incremental changes for each (aparently) full backup. It's really easy to implement rsnapshot, especially if all you want is to have a copy of all the files on your system for manual inspection and recovery. It is significantly more complex to use for a full recovery than dump/restore (and the issues can be esoteric).

I would ignore zfs unless you have a really good reason to want it now, even though a zfs snapshot might theoretically solve your backup problem. It's great, but its benefits and complexity can be deferred until you gain competence.

Most of all, I recommend that you consider why you are re-installing FreeBSD up to four times a day. You should not need to be doing that. So you should not need to be recovering a freshly installed system...

Cheers,
 
The idea of having a bootable disk that will reinstall a snapshot of a system is sometimes called a "bare-metal restore". I've been tempted to do something like that at times. Starting with mfsBSD, it would not be too hard to do. It may be possible to script an existing tool like Clonezilla to do this. If it didn't insist on uselessly backing up swap partitions, Clonezilla would almost be there already.

The problem is that a) the people who could use it mostly don't need it (admins), and b) the people who think they need it (end users) would usually be unhappy when it overwrites their existing data.

Leave that kind of thing laying around, and somebody will boot from it, and happily answer yes to all the questions that say "Are you sure you really want to blow away all the current data and overwrite it with this old backup? Really?"
 
You must log in or register to reply here.
Back
Top