Re: file system setup for new system - recommendations?
From: Gary Mulder (gmulder_at_infotechfl.com)
Date: 08/09/04
- Previous message: Kris Kennaway: "Re: kernel preemption in 5.2.x"
- In reply to: Jay O'Brien: "Re: file system setup for new system - recommendations?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 09 Aug 2004 16:56:19 -0400 To: "Jay O'Brien" <jayobrien@att.net>, FreeBSD - questions <questions@freebsd.org>
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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
- Previous message: Kris Kennaway: "Re: kernel preemption in 5.2.x"
- In reply to: Jay O'Brien: "Re: file system setup for new system - recommendations?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
