UFS Backup

I have been folowing this, every thing got copyed, but it wont load =\
It's trying to find kernel on ad0, but hdd with new system is on ad2.

How to fix it ?
 
you need to mark ad2 bootable and remove bootable flag from ad0
for that use fdisk, sorry, can't tell anything more, I don't use gpt, and i'm unfamiliar with fdisk.


as an alternative, you can use sysinstalls fdisk. (just be careful, not to mess things up)
sysinstall ->> configure > fdisk, select ad2, pick slice, and press S, at left bootable flag (A or something like that will appear)
Then press W to save changes.
for ad0 you have to do same, but in this case, you will lose flag A, again press W

Then press cancel all the the way to exit, or hit Ctrl+C, and abort.

Hopefully this will do the trick

P.S. make sure you can boot from ad2. There might be some bios setting that can prevent it (But I highly doubt this is the case. I had this problem, and to solve it, I had to do change some bios settings related to RAID [on matherboard], anyway, this is not your case)

Good luck, and don't mess up ;)
Perhaps if you can, try on emulator
 
sysinstall ->> configure > fdisk
It showes NOTHING there O_O

Code:
    FreeBSD Disklabel Editor


Part      Mount          Size Newfs   Part      Mount          Size Newfs
----      -----          ---- -----   ----      -----          ---- -----












The following commands are valid here (upper or lower case):
C = Create        D = Delete   M = Mount pt.            W = Write
N = Newfs Opts    Q = Finish   S = Toggle SoftUpdates   Z = Custom Newfs
T = Toggle Newfs  U = Undo     A = Auto Defaults        R = Delete+Merge

Use F1 or ? to get more help, arrow keys to select.

What to do ?

Ps: 100 % that there is partitions, I know because right now it's booted from them.
(0:ad(2,f)/boot/loader)
 
It sounds like the same "nothing to install to" where there
were partitions on ad10_OR_da10 (sata on pci controller)
and a 8-13-2009 disc1 sysinstall on cdr. My recollection of
which screen is already vague though, but highly likely it is
the one shown in the previous post. Time to commit to disk, and
"no device node found for /dev/ad10(da10)" or nearly-the-same
error occured (I tried about 6 times from the start.) Another
thread yesterday/today mentions that error...
 
perhaps try gpt and or gpart (if if you're using FreeBSD-7)
or gpart if you're trying freebsd-8

This is really weird
 
Persistent 'root restore' problem

My system disk was setup with /, /var, /tmp, & /usr mount points which I would like to maintain for more than sentimental reasons, there are many absolute paths to files using this architecture. Now I am rebuilding the system disk, I am using Fixit from the dist disk to boot the system, have created new partitions, filesystems etc, and the base installation files.

The back up files are on another disk.

Fixit only permits the restored files to be mounted under /mnt/ so there are /mnt/ad0s1a, /mnt/ad0s1d, /mnt/ad0s1e and /mnt/ad0s1f respectively.

When I execute the reboot I can relatively smoothly mv the /mnt/* files to their respective locations, except for the /* files. There is a string of messages about files exist or busy etc. So many files, especially the critical /etc/* files are not installed.

If I omit the base installation from the setup then I get "/bin/cp missing" on the mv attempt, indeed there is no /bin directory.

What is the correct way of doing this restore, I am sure there is one but I do not have it.

Thanks
 
I don't think I understand what you're really trying to do.

If you want to move system from one disk (partition/slice etc) to another, you should not use mv/cp instead use combination of dump restore

mount formated destination, and source (For this i create /mnt/src and /mnt/dst directories :) ), cd to /mnt/dst and execute:
Code:
# dump -0Laf - /dev/ad0s1d | restore -rf -
# cd /mnt
# umount /mnt/src /mnt/dst
then repeat for eash FS you want to move.
Read update 1 on 1st post

To restore from dump on another fs, again, newfs new target, mount bough fs on /mnt/src /mnt/dst (or whatever you prefer), cd to /mnt/dst and do what's written in Restore System in 1st post


Sorry, if this is not what you wanted, to know, but I didn't really understand what you want to do.
Hope, this helps, if not, let me know, here
 
I am trying to update my O/S [v 6.0], made prior dump of /, /var, /tmp, & /usr. In the process of updating the system disk got clobbered and I am now trying to restore same.

How do I get the original / dump (root dump) to the new / partition slice. It is in /mnt/ad0s1a after Fixit.
 
Well, if you newfs'ed filesystem, that contained, dumps, than nonehow....
otherwise, newfs /dev/ad0s1a, mount fs with dumps, mount /dev/ad0s1a and cd to it.... and read restore System paragraph in 1st post, it explains everything
 
killasmurf - really interesting for the desktop bsd user who wants a short term back up.

Monkey - I do agree with you on most if not all the points you have raised a local back up is not a real back up it is a temporary solution to a problem.

Here is my back up methodology:

I clone all my data drives once a month onto 3 disk's one goes to a safe deposit box in a bank, another goes to a friend of mine in Manchester (roughly 25 miles away from me) another sits in a fire proof safe in my home.
I have tape back ups every 2nd day of my mission critical files, one gets dropped in a bank deposit safe (every 7 day's I go and collect the last weeks tapes) one set goes in the fireproof safe in my home and another goes to a relatives house who drives past me on the way to and from work who is also in IT.
I have a nightly local back ups of my main work stations to a hard drive.
I have copies of the really important stuff stashed at various places updated as needed.
All my financial records like receipts, invoices, tax records, my will, etc I have hard copies and digital copies stored with my solicitor, my bank deposit box, my family deposit box, my fire proof safe and 3 relatives.

Some might call that excessive but when I started in IT professionally I worked for a company that lost 6 years of data (Ironic really as they where a back up holding company for legal records) and where really lost without it and if it wasn't for one guy who had a copy of everything they would have gone bust, I don't want that happening to me so I have copies of copies.
 
my backup system

160 GB SATA 2 disk

Code:
dd if=/dev/ad1 of=/dev/ad3 bs=8192

dd processing 09-Sep-2009-01:30:01  starting
dd processing 09-Sep-2009-03:51:57  finished
 
Though I find your guide very enlightening and concise, personally I find myself very uncomfortable with dump.

As other users have stated, doing either one-shot or incremental backups with tar, copying/cloning entire filesystems with tar, or plain old dd, seems to work best for both low and high end systems.

My strategy with one-shot short term backups for upgrading/testing purposes is by moving filesystems (copying with tar). This provides two benefits: 0. you just need enough spare continuous backup space, no matter of disk layout or geometry. 1. You can access your files right away (so you can grab your kernel or config files on the fly). Afterwards, you can do a proper backup.

Properly stored and managed, external hdd are a good way to do backups with tar (multiple copies are a must for serious backups). But I wouldn't count on expecting a lifetime of 20-something years. 10 years is more than enough, and afterwards, move all your data to a more recent (and higher capacity) technology. I did from floppies to cds, from cds to dvds (sometimes by storing .iso files), and from dvds to hdd (when storing to dvds didn't made the cut).
 
about tar: you can do that with dump/restore as well.

Anyway, I don't use UFS anymore....

ZFS for life ;)
 
killasmurf86 said:
Blue-ray..... 1 scratch and .......

cloud computing....
Check "network security monitoring with freebsd" video clip in Freebsd community page

Where is that "Freebsd community page"?
Link to that video clip?
 
O, I thought about finding video link, at your first posted link (community), but it wasn't there.
Last (third) link, you posted, I've found on my own, via google.
I thought it was something similar, but not same.

Thanks.
 
Hi,
Thanks so much for this wonderful post.
I tried to use your method on a FreeBSD LiveCD, and it did not work. I got to the point where I am able to create the slices in the partition (ad0s1), and mount them to /mnt/tmp. However, as soon as I try to "cd" into it, I get an error. I tried your method on a FreeNAS iso (downloaded from http://sourceforge.net/projects/fre...2/FreeNAS-i386-LiveCD-0.7.2.5543.iso/download). I am definitely doing something incorrect (pardon my lack of sufficient literacy on BSD - I have been conditioned in the M$FT world for the past 10 years).
This is what I am doing:
My Laptop: Very old Dell Inspiron machine with 20GB HDD, and 256 MB RAM. (I want to repurpose this old machine as a FreeNAS server for my home PCs)
- Boot from the FreeNAS Live CD (this is based on FreeBSD variant - nanoBSD) (correct me if I am mistaken)
- Once the system is loaded, I choose option "6" - "Shell prompt"
- At the shell prompt I did a "df -h" and got the mounted file system.
- Using fdisk, and bsdlabel I created a slice, and partitioned it.
- Then I mounted the first partition (mount /dev/ad0s1a /mnt/tmp)
- However, I could not cd into /mnt/tmp - it errors out with "file or device not found".

Can you please advice, as to what I am doing wrong? OR Perhaps my question should be, if dump, and restore work on systems booted through LiveCD (since the LiveCD filesystem is loaded in the RAM).

Any insight would be helpful.
Thanks.
-SR
 
Well if you told what you did exactly like you did, then it looks like you did everything correctly.
I haven't used FreeNAS and NanoBSD so I don't know their specifics.

dump and restore should work from anything (unless you don't try to write to Read-Only filesystem) :)

You said you sliced and formated your disk and mounted it to /mnt/tmp/?
Did you create /mnt/tmp/? It won't be created automatically, but it should give error, if you try to mount to non-existing directory (Maybe this doesn't apply on FreeNAS) :D
 
Thanks for your insight Killasmurf86.

I guess you may have been correct. Anyhow, I retraced my steps once again. And this time everything did go through fine. However, the FreeNAS did not boot as expected (specifically, it did go through the boot process, but it failed to mount the root). Anyhow, after a long investigative work (downsides of not having a formal FreeBSD knowledge), I was finally able to figure out another method to make this work.

I thought to myself, if the LiveCD is able to install it to a disk (it "does" wipe out other partitions), then I should be able to modify that "install script", so that I can install FreeNAS to a "slice". I researched for the install script on the FreeNAS source tree and viola found the file I was looking for : http://support.freenas.org/browser/freenas/legacy/etc/inc/install.inc

This gave me the steps on how to install it to a HDD - I followed the scripted steps in "function install_harddrive_image($harddrive)". I am happy to report that FreeNAS is running in a dual-boot / multi-boot scenario (though officially it is not supported).

Needless to say, your post was quite helpful to get me started.

-SR
 
Thanks for writing this tutorial; I plan to use it step by step when I have enough nerves to try it :e

But on googling around there are also some remarks about first steps that you perhaps might want to include so your post becomes a 'really really really contains every step' guide?

For example:
- One seems to be needing the label from each disk and slice and the content of /etc/fstab?
- How to verify the dump just being made? (I mean, a backup is useless if, once you need it, it can't be restored).
- How to exclude directories from being dumped?
-?
 
Caliante said:
Thanks for writing this tutorial; I plan to use it step by step when I have enough nerves to try it :e

But on googling around there are also some remarks about first steps that you perhaps might want to include so your post becomes a 'really really really contains every step' guide?

For example:
- One seems to be needing the label from each disk and slice and the content of /etc/fstab?
That's too much info, we have slices, eli, gpt... one must know what he's doing after all

Caliante said:
- How to verify the dump just being made? (I mean, a backup is useless if, once you need it, it can't be restored).
md5(5) or sha256(5) or any other

Caliante said:
- How to exclude directories from being dumped?
There is manual for such details :)
dump(8), restore(8)

:)
 
killasmurf86 said:
That's too much info, we have slices, eli, gpt... one must know what he's doing after all


md5(5) or sha256(5) or any other


There is manual for such details :)
dump(8), restore(8)

:)

I beg to differ, there is a manual for [cmd=]$ dump -0Lauf /path/to/backups/ad0s1d.dump /dev/ad0s1d[/cmd] as well, to name just one.

But no problem I will do it myself.
 
AFAIK...
Caliante said:
For example:
- One seems to be needing the label from each disk and slice and the content of /etc/fstab?

Not sure what you are asking. The dump program needs to know the /dev entry name of the disk/partition with the filesystem that you want to dump. This is easily gotten from the df command, as well as /etc/fstab although fstab is just a static table and might not reflect actual current mounted filesystems and their underlying device node names. That is, /etc/fstab could be wrong. Also fstab only lists those filesystems that would automatically be mounted at boot time, plus random others, depend on what the sysadmin has stuck in there. But filesystems can be living in other device partitions and never get listed in fstab. Yet they would still be eligible for dump. The upshot is that dump simply needs (an accurate) device node name with a valid filesystem in it.

Caliante said:
- How to verify the dump just being made? (I mean, a backup is useless if, once you need it, it can't be restored).

I don't know of any simple way to verify the dump other than to restore it in a spare partition and see if you like the result. But I would definitely try to catch all I/O errors from dump and dump tries hard to flag those things, so this would catch most problems. And you can always just do a "[cmd=]dd of=/dev/null bs=XX if=TAPEDRIVE[/cmd] to make sure that you can read the entire dump from the media.

Caliante said:
- How to exclude directories from being dumped?

I don't know of a way to do that simply because dump does it work OUTSIDE of the filesystem. It is an inode-level backup program and has no real knowledge of directories per se. NB that it also backs up FILESYSTEMS, which are only *parts* of the tree. There is no way to tell dump to backup an entire system (unless there is only one filesystem, which is rare).

The easiest way to understand this is to look at the output of df. It lists all MOUNTED filesystems. Basically dump operates on ONE and only one of those lines of df's output. So if /var is a separate filesystem (and therefore has its own line entry in df), then you can dump it, or not. But there is no way to, for example, only backup /usr/lib (or not), since /usr/lib is rarely its own filesystem.

You want to do backups WITHIN the entire file space, choosing directories at will, then use a file space-level program, like tar or cpio. These programs allow you to say what directories to archive.

Here is an example of df output:

Code:
$ df
Filesystem      1K-blocks     Used    Avail Capacity  Mounted on
/dev/da0s1a        126702    74398    42168    64%    /
devfs                   1        1        0   100%    /dev
/dev/da0s1d        253678   172438    60946    74%    /var
/dev/da0s1e        126702    11316   105250    10%    /tmp
/dev/da0s1f       2939197  2162978   541083    80%    /usr
/dev/da1s1d       3107529  2561610   483768    84%    /home

On this system, you can see there are FIVE mounted filesystems (plus /dev, which doesn't count). A single dump command can and does only deal with ONE of those five filesystems. You can choose to dump as few or many as you wish, but each one will require its own dump command. You cannot choose to dump only parts of one of those five filesystems. If you are using tape media, a common technique is to append multiple dumps as separate TAPE FILES, all on the same tape, like this:

Code:
# dump 0Labf 100 /dev/nsa0 /dev/da0s1a
# dump 0Labf 100 /dev/nsa0 /dev/da0s1d
# dump 0Labf 100 /dev/nsa0 /dev/da0s1e
# dump 0Labf 100 /dev/nsa0 /dev/da0s1f
# dump 0Labf 100 /dev/sa0 /dev/da1s1d

They will all go on one tape (presuming the tape is large enough, else dump will automatically prompt for a new tape). Note that the no-rewind device /dev/nsa0 is used for all but the last dump.

To restore only the 3rd filesystem, for example, you can use the mt command to skip tape files:

# mt -f /dev/nsa0 fsf 2

will position the tape at the beginning of the 3rd dump, ready for the restore, in this case, of the /tmp filesystem.

# restore ivbf 100 /dev/nsa0

I like to use the interactive mode of restore, because you get to see what is going to happen before it happens...
 
Back
Top