Date: Mon, 09 Aug 2004 16:56:19 -0400 From: Gary Mulder <gmulder@infotechfl.com> To: "Jay O'Brien" <jayobrien@att.net>, FreeBSD - questions <questions@freebsd.org> Subject: Re: file system setup for new system - recommendations? Message-ID: <4.2.0.58.20040809151349.01088d70@mail.infotechfl.com> In-Reply-To: <411707A4.8060806@att.net> References: <200408082329.30928.alias2@crotchett.com> <41142284.7060304@att.net> <200408082104.04026.alias2@crotchett.com> <52BCCE6B-E9B5-11D8-9C00-000393BB56F2@HiWAAY.net> <200408082329.30928.alias2@crotchett.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just my $0.02NZ on this question: First off partitions - The first thing I do in single user mode in FreeBSD is mount /usr to access basic commands such as more, etc., so what is the point of having / and /usr on separate partitions? Thus I usually allocate 4 to 8GB to / and don't have a separate /usr partition. Can anyone posit a problem with combining / and /usr? It was (as far as I know) an old rule of thumb to have swap twice your physical memory size. This was in the good ole days when memory was expensive and disk was comparatively cheap. These days if you are having to use two times your memory's worth of swap in normal activity it is time to buy more memory. However, since crash dumps are stored in the swap partition (note that they're not by default, you need to define dumpdev in /etc/rc.conf, see rc.conf(5) for more details) you'll want your swap as large as the maximum memory you expect to have on the system. /tmp should be on a separate partition to prevent overflow of the / partition. A few GB of disk here is nice, dependent on the nature of programs you plan to run. /var should be sized appropriate to what will be logged/stored in /var. For a Desktop, a few GB is probably sufficient. For a server with mail, web, ftp, etc. services 4-8GB is nice. The remainder is traditionally allocated to /home. Next Vinum and backups - Vinum provides a number of configurations (RAID 0, 1, 1+0, 0+1, 5, etc.) for data redundancy. It requires two or more disks (depending on which RAID level), typically of the same type and size on separate controllers. It is somewhat complex to setup but provides a lot of flexibility in configuration. It is important to note that using RAID for data redundancy is NOT data backup. A redundant RAID configuration will happy mirror file system corruption, inadvertent user file deletions, etc. Backup however implies a secure and independent copy of the primary system data. Ideally this copy is not just kept on the same disk as the primary data. How useful are your backups if you lose the drive that has both your system and its backups? -------- Here is a proposed setup for a small to medium sized Unix server with say a 120GB and 80GB ATA disks: Set up the 80GB disk as the master on the first controller. Set up the 120GB drive as master on the second controller and the CDROM drive as slave. Side Note: Accessing the CDROM drive with this configuration may then greatly impact performance of the 120GB drive and you may instead want to put the 120GB drive as the slave on controller 1. However there is then the chance that if either hard drive goes bad it will hang controller 1 (a known problem with ATA controllers) and thus the system. If you use the CDROM infrequently I feel it is best to have the second hard drive on controller 2 as master and CDROM as slave. YMMV. Partition map: / - 8GB swap - 1GB /tmp - 4GB /var - 4GB /home - 63GB (ie. the rest of the disk). Next use the following instructions to set up vinum to mirror the 80GB drive to the first 80GB of the 120GB drive. You have to be VERY careful with setting the partition types, calculating the disklabel offsets and corresponding vinum offsets and making sure the disk labels are written correctly: http://devel.reinikainen.net/docs/how-to/Vinum/ The remaining 40GB of the 120GB drive can then be mounted as an unmirrored /backup partition. Alternatively, if you have two identical drives (or a third smaller drive) configure a mirrored /backup partition (or dedicate the third drive) for even more backup redundancy. There are then a number of methods to perform backup, such as dump/restore, tar, cpio, Amanda, rsync-backup. My preference is GNU tar due to its portability among Unixes and other OSes. An example of creating a compressed full backup would be: nice tar --exclude "/backup" --totals -cj -f /backup/`date +%s``.tar.bz2 / This could be run out of cron say every night or weekend. With some scripting it could be made more space efficient by using the "--listed-incremental" option of GNU tar to say to full backups each weekend and incremental backups each day. One program I have recently looked into is rdiff-backup. It uses rsync libraries to make an uncompressed mirror (as in copy, not RAID 1) of the entire system and then keep backward diffs of changes to the system so that it is very easy and fast to do point-in-time restores (or even use the mirror directly with chroot in extremis). The only issue with rdiff-backup that I can see is that unlike traditional full image plus incremental backups, rdiff uses current mirror image minus incremental diffs, which means if you lose your mirror image you can no longer do point-in-time restores of the entire system. You can however restore files that have changed from the diffs. Gary -- Gary Mulder <mailto:gary.mulder@infotechfl.com> Info Tech, Inc. 5700 SW 34th Street, Suite 1235 Phone: (352) 381-4400 Gainesville, FL 32608 Fax: (352) 381-4444
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.0.58.20040809151349.01088d70>