HOWTO: Install, backup and restore a reliable FreeBSD 8.2 system

danbi said:
One thing I always wonder is why people seems to keep on using the released FreeBSD versions to bootstrap new installations. True, this is how you get FreeBSD installed for the very first time or in case of total disaster. However, once you have at least one working FreeBSD system for the particular CPU architecture, you may build your own install 'distribution'. You can control the layout of your distribution and not have your scripts fail when the release puts things differently. You will also need only one medium to deal with.
Why bootstrap? It seems to work AFAICT, judging by the diff output. If it works and there is nothing that horribly inefficient or slow about how it works, that's good enough for me. My main concern is that I want to be informed if something is wrong with this process that I don't know about, so that's in part why I post this.

I guess I'm not really sure of what the advantages are of (if I understand correctly what you are suggesting) using your home rolled installation USB to use in order to install things etc.
Probably I am too much die-hard in this regard but I rarely trust prepackaged things. Here I will outline how to create an self-replicating FreeBSD-stable system. :)
Thanks. I will try and look at it and understand it some more when I get some free time.
 
bbzz said:
This is really great, lots of effort in here.
Thanks, it was indeed a lot of effort to get to this point. Especially that since to test requires lengthy reboot sequences. Perhaps I could have used a VM but I just wanted additional surety so I used a physical machine.
bbzz said:
Two questions:
1) You mentioned "...in preparation for dedup..." Aside from dedup which would prefer to run SHA256; any other reason to run it instead of fletcher4? That is, how prone is it to collisions in real life?
It is very, very non-prone to collisions. See here. It is slower (not sure how much). Read also here.

2) Since dedup is not currently available on 8.2-RELEASE, will it work retroactively, i.e asynchronously as well as synchronously on FreeBSD making it possible to dedup already written data. Seeing how this is massively great feature and all.
Good question. I'm not really sure what the answer is there. I will figure that one out when 9.0 is released - I'd really need to research that one. Perhaps one could always do a full system restore (I always like to test such a thing out on spare drives first, just in case something goes wrong, rather than your working system drives.)
 
UNIXgod said:
Wow. Bookmarked! Looking forward to trying this stuff!
Thanks. Look forward to seeing if you have any comments or corrections. Good luck. I will be happy to help if you should need it. Glad to see that both you and wblock who have helped me on the kernel compile walkthrough have checked out this thread. Thanks guys.
 
The idea to create your own bootable distribution really comes down to few things:

1) You get the latest -stable, with all new drivers and fixes. As of today, for example, this means you get LSI2008 driver (mps) and ZFS v28 in 8-stable. This is NOT available in 8.2-release. If you need such features at install time, you need to use an 'homegrown' distribution anyway. Sure, you can do in-place upgrade/reinstall of the system but few people do it, and then you essentially go the same route.

2) On your own distribution media you can add your scripts, do few customisations if you wish (rarely needed). An good example of such "homebrew distribution" is the mfsbsd system.

3) This is how UNIX replicates :) There is nothing 'homegrown' in here -- you use the very recommended procedure to install FreeBSD on a new partittion. That partittion just happens to be on another computer.

On dedup, sha256 and ZFS v28:

ZFS v28 is already in -stable as of yesterday. Great! :)
In order to dedup, you need to upgrade your pools to v28 and then write any data you want to dedup. The DDT are not automatically (re)built for already stored data. Therefore, setting sha256 before upgrading to v28 cannot help dedup in any way -- it can of course help better detect colissions.

This guide is very good. You have put a lot of effort to cover many of the details.
 
danbi said:
The idea to create your own bootable distribution really comes down to few things:

1) You get the latest -stable, with all new drivers and fixes. As of today, for example, this means you get LSI2008 driver (mps) and ZFS v28 in 8-stable. This is NOT available in 8.2-release. If you need such features at install time, you need to use an 'homegrown' distribution anyway. Sure, you can do in-place upgrade/reinstall of the system but few people do it, and then you essentially go the same route.

2) On your own distribution media you can add your scripts, do few customisations if you wish (rarely needed). An good example of such "homebrew distribution" is the mfsbsd system.

3) This is how UNIX replicates :) There is nothing 'homegrown' in here -- you use the very recommended procedure to install FreeBSD on a new partittion. That partittion just happens to be on another computer.
Thank you for answering. I guess if I decide to use stable in future, I can use this. Until then I'm sticking with RELEASE. About the only thing I really need v28 for is to dedup are some of my old backups from various systems, that also include backups of other systems. No doubt there is a LOT of duplicated stuff in there, but it's more painful (not to mention error prone) to have to go through and sort through everything than to put them all on a deduped pool and be done with it. And that can wait. :)
danbi said:
On dedup, sha256 and ZFS v28:

ZFS v28 is already in -stable as of yesterday. Great! :)
In order to dedup, you need to upgrade your pools to v28 and then write any data you want to dedup. The DDT are not automatically (re)built for already stored data. Therefore, setting sha256 before upgrading to v28 cannot help dedup in any way -- it can of course help better detect colissions.
True. I should probably remove that from the guide or change the wording. Using sha256 should minimize to the utmost the chance of a bit flip colliding. That's about it.

danbi said:
This guide is very good. You have put a lot of effort to cover many of the details.
Thanks very much. It took a lot of effort. :) So far 13 downloads of the scripts, I wonder if anyone has actually tried some of this out yet. If anyone has, please share your experiences here.
 
Holy crap, huge effort here, thank you. Looking forward to digesting everything and implementing. Again, thank you.
 
dkeav said:
Holy crap, huge effort here, thank you. Looking forward to digesting everything and implementing. Again, thank you.
No problem. I'm glad you took the time to thank me and post on the thread. Let me know how you go with it. I welcome you and others to contribute some feedback and any suggestions/discussion/improvement etc. to make this a better solution. So far there are 42 downloads of these install scripts, so it would be nice to hear from others if they have made it all the way through.
 
Thank you very much for this.

I always was a little reluctent to use a zfs only system.
But after reading your howto, i think i am going to make the switch.

you mentioned using the old disk, i also had this issue while testing with ZFS
But on the Freenas FAQ i found i nice script that could be used to wipe your disk of MBR and ZFS/GEOM Meta data.

Code:
#!/bin/sh
echo "What disk do you want"
echo "to wipe? For example - da1 :"
read disk
echo "OK, in 10 seconds I will destroy all data on $disk!"
echo "Press CTRL+C to abort!"
sleep 10
diskinfo ${disk} | while read disk sectorsize size sectors other
do
        # Delete MBR and partition table.
        /bin/dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
        # Delete GEOM metadata.
        /bin/dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` count=2
done

source http://wiki.freenas.org/faq:0129


regards
Johan Hendriks
 
Sylhouette said:
Thank you very much for this.

I always was a little reluctent to use a zfs only system.
But after reading your howto, i think i am going to make the switch.
No problem, thank YOU for contributing here. Please let me (and the rest of us) know how it works out for you.
 
I'd just like to add my thanks as well for your hard work.
I'm still in the process of getting my FreeBSD box set up the way I want and your post is going to be a great help to me.
I won't be using your scripts directly just as yet since my use case is slightly different (encrypted ZFS NAS box with Crashplan for offsite backups) and I need to get my head round how your scripts would fit into that.
 
mikedm said:
I'd just like to add my thanks as well for your hard work.
I'm still in the process of getting my FreeBSD box set up the way I want and your post is going to be a great help to me.
I won't be using your scripts directly just as yet since my use case is slightly different (encrypted ZFS NAS box with Crashplan for offsite backups) and I need to get my head round how your scripts would fit into that.
Thanks for letting me know. Keep us informed as to how it works out for you. Good luck.
 
Great work! I'm on FreeBSD 9 BETA 3 and I noticed that there are two additional zfs properties that need to be added to the list fbsd_readonly_properties to make the script work, they are:
Code:
refquota
refcompressratio
 
That was an extreme amount of work; thank you very much for it. I will try to use it one day, when I have enought guts :D
 
kpa said:
Great work! I'm on FreeBSD 9 BETA 3 and I noticed that there are two additional zfs properties that need to be added to the list fbsd_readonly_properties to make the script work, they are:
Code:
refquota
refcompressratio
Thanks. If possible, let me know how it goes when it gets to RELEASE, and if there is anything special to do when you upgrade.
 
carlton_draught said:
Thanks. If possible, let me know how it goes when it gets to RELEASE, and if there is anything special to do when you upgrade.

Thanks for zxfer; it's been quite helpful.

The manual doesn't state how one specifies an SSH port when using the -O and -T options.

Here's what worked for me:

Code:
-O "-p 6593 -i ~/my.key root@example.com"

Hope that helps someone.
 
Back
Top