--- title: Κεφάλαιο 19. Αποθηκευτικά Μέσα part: Μέρος III. Διαχείριση Συστήματος prev: books/handbook/audit next: books/handbook/geom showBookMenu: true weight: 23 params: path: "/books/handbook/disks/" --- [[disks]] = Αποθηκευτικά Μέσα :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 19 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/disks/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[disks-synopsis]] == Σύνοψη Το κεφάλαιο αυτό καλύπτει την χρήση των δίσκων στο FreeBSD. Περιλαμβάνει δίσκους που υποστηρίζονται από μνήμη, δίσκους συνδεδεμένους απευθείας στο δίκτυο, τις τυπικές συσκευές αποθήκευσης SCSI/IDE, καθώς και συσκευές που χρησιμοποιούν διεπαφή USB. Αφού διαβάσετε αυτό το κεφάλαιο, θα ξέρετε: * Την ορολογία που χρησιμοποιεί το FreeBSD για να περιγράψει την οργάνωση των δεδομένων στο φυσικό μέσο του δίσκου (partitions - κατατμήσεις - και slices). * Πως να προσθέσετε νέους σκληρούς δίσκους στο σύστημα σας. * Πως να ρυθμίσετε το FreeBSD να χρησιμοποιεί συσκευές αποθήκευσης USB. * Πως να ρυθμίσετε εικονικά συστήματα αρχείων, όπως δίσκους που αποθηκεύονται σε μνήμη RAM. * Πως να χρησιμοποιήσετε quotas για να περιορίσετε τη χρήση χώρου στο δίσκο. * Πως να κρυπτογραφήσετε δίσκους για να τους ασφαλίσετε από επιθέσεις. * Πως να δημιουργήσετε και να γράψετε CD και DVD στο FreeBSD. * Πως να χρησιμοποιήσετε προγράμματα λήψης αντιγράφων ασφαλείας στο FreeBSD. * Τι είναι οι εικόνες (snapshots) σε ένα σύστημα αρχείων και πως να τις χρησιμοποιήσετε αποδοτικά. Πριν διαβάσετε αυτό το κεφάλαιο, θα πρέπει: * Να ξέρετε πως να crossref:kernelconfig[kernelconfig,ρυθμίσετε και να εγκαταστήσετε ένα νέο πυρήνα του FreeBSD]. [[disks-naming]] == Device Names The following is a list of physical storage devices supported in FreeBSD and their associated device names. [[disk-naming-physical-table]] .Physical Disk Naming Conventions [cols="1,1", frame="none", options="header"] |=== | Drive type | Drive device name |IDE hard drives |`ad` or `ada` |IDE CD-ROM drives |`acd` or `cd` |SATA hard drives |`ad` or `ada` |SATA CD-ROM drives |`acd` or `cd` |SCSI hard drives and USB Mass storage devices |`da` |SCSI CD-ROM drives |`cd` |Assorted non-standard CD-ROM drives |`mcd` for Mitsumi CD-ROM and `scd` for Sony CD-ROM devices |Floppy drives |`fd` |SCSI tape drives |`sa` |IDE tape drives |`ast` |Flash drives |`fla` for DiskOnChip(R) Flash device |RAID drives |`aacd` for Adaptec(R) AdvancedRAID, `mlxd` and `mlyd` for Mylex(R), `amrd` for AMI MegaRAID(R), `idad` for Compaq Smart RAID, `twed` for 3ware(R) RAID. |=== [[disks-adding]] == Adding Disks This section describes how to add a new SATA disk to a machine that currently only has a single drive. First, turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturers. Reboot the system and become `root`. Inspect [.filename]#/var/run/dmesg.boot# to ensure the new disk was found. In this example, the newly added SATA drive will appear as [.filename]#ada1#. For this example, a single large partition will be created on the new disk. The http://en.wikipedia.org/wiki/GUID_Partition_Table[ GPT] partitioning scheme will be used in preference to the older and less versatile MBR scheme. [NOTE] ==== If the disk to be added is not blank, old partition information can be removed with `gpart delete`. See man:gpart[8] for details. ==== The partition scheme is created, and then a single partition is added: [source,shell] .... # gpart create -s GPT ada1 # gpart add -t freebsd-ufs ada1 .... Depending on use, several smaller partitions may be desired. See man:gpart[8] for options to create partitions smaller than a whole disk. A file system is created on the new blank disk: [source,shell] .... # newfs -U /dev/ada1p1 .... An empty directory is created as a _mountpoint_, a location for mounting the new disk in the original disk's file system: [source,shell] .... # mkdir /newdisk .... Finally, an entry is added to [.filename]#/etc/fstab# so the new disk will be mounted automatically at startup: [.programlisting] .... /dev/ada1p1 /newdisk ufs rw 2 2 .... The new disk can be mounted manually, without restarting the system: [source,shell] .... # mount /newdisk .... [[usb-disks]] == USB Storage Devices Many external storage solutions, such as hard drives, USB thumbdrives, and CD/DVD burners, use the Universal Serial Bus (USB). FreeBSD provides support for these devices. === Configuration The USB mass storage devices driver, man:umass[4], is built into the [.filename]#GENERIC# kernel and provides support for USB storage devices. For a custom kernel, be sure that the following lines are present in the kernel configuration file: [.programlisting] .... device scbus device da device pass device uhci device ohci device ehci device usb device umass .... Since the man:umass[4] driver uses the SCSI subsystem to access the USB storage devices, any USB device will be seen as a SCSI device by the system. Depending on the USB chipset on the motherboard, `device uhci` or `device ohci` is used to provide USB 1.X support. Support for USB 2.0 controllers is provided by `device ehci`. [NOTE] ==== If the USB device is a CD or DVD burner, man:cd[4], must be added to the kernel via the line: [.programlisting] .... device cd .... Since the burner is seen as a SCSI drive, the driver man:atapicam[4] should not be used in the kernel configuration. ==== === Testing the Configuration To test the USB configuration, plug in the USB device. In the system message buffer, man:dmesg[8], the drive should appear as something like: [source,shell] .... umass0: USB Solid state disk, rev 1.10/1.00, addr 2 GEOM: create disk da0 dp=0xc2d74850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C) .... The brand, device node ([.filename]#da0#), and other details will differ according to the device. Since the USB device is seen as a SCSI one, `camcontrol` can be used to list the USB storage devices attached to the system: [source,shell] .... # camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) .... If the drive comes with a file system, it can be mounted. Refer to <> for instructions on how to format and create partitions on the USB drive. [WARNING] ==== Allowing untrusted users to mount arbitrary media, by enabling `vfs.usermount` as described below, should not be considered safe from a security point of view. Most file systems in FreeBSD were not built to safeguard against malicious devices. ==== To make the device mountable as a normal user, one solution is to make all users of the device a member of the `operator` group using man:pw[8]. Next, ensure that the `operator` group is able to read and write the device by adding these lines to [.filename]#/etc/devfs.rules#: [.programlisting] .... [localrules=5] add path 'da*' mode 0660 group operator .... [NOTE] ==== If SCSI disks are installed in the system, change the second line as follows: [.programlisting] .... add path 'da[3-9]*' mode 0660 group operator .... This will exclude the first three SCSI disks ([.filename]#da0# to [.filename]#da2#)from belonging to the `operator` group. ==== Next, enable the man:devfs.rules[5] ruleset in [.filename]#/etc/rc.conf#: [.programlisting] .... devfs_system_ruleset="localrules" .... Next, instruct the running kernel to allow regular users to mount file systems. The easiest way is to add the following line to [.filename]#/etc/sysctl.conf#: [.programlisting] .... vfs.usermount=1 .... Since this only takes effect after the next reboot use man:sysctl[8] to set this variable now. The final step is to create a directory where the file system is to be mounted. This directory needs to be owned by the user that is to mount the file system. One way to do that is for `root` to create a subdirectory owned by that user as [.filename]#/mnt/username#. In the following example, replace _username_ with the login name of the user and _usergroup_ with the user's primary group: [source,shell] .... # mkdir /mnt/username # chown username:usergroup /mnt/username .... Suppose a USB thumbdrive is plugged in, and a device [.filename]#/dev/da0s1# appears. If the device is preformatted with a FAT file system, it can be mounted using: [source,shell] .... % mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/username .... Before the device can be unplugged, it _must_ be unmounted first. After device removal, the system message buffer will show messages similar to the following: [source,shell] .... umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc2d74850 umass0: detached .... === Further Reading Beside the <> and crossref:basics[mount-unmount,Mounting and Unmounting File Systems] sections, reading various manual pages may also be useful: man:umass[4], man:camcontrol[8], and man:usbconfig[8] under FreeBSD 8.X or man:usbdevs[8] under earlier versions of FreeBSD. [[creating-cds]] == Creating and Using CD Media === Introduction CD media provide a number of features that differentiate them from conventional disks. Initially, they were not writable by the user. They are designed so that they can be read continuously without delays to move the head between tracks. They are also much easier to transport between systems. CD media do have tracks, but this refers to a section of data to be read continuously and not a physical property of the disk. For example, to produce a CD on FreeBSD, prepare the data files that are going to make up the tracks on the CD, then write the tracks to the CD. The ISO 9660 file system was designed to deal with these differences. To overcome the original file system limits, it provides an extension mechanism that allows properly written CDs to exceed those limits while still working with systems that do not support those extensions. The package:sysutils/cdrtools[] port includes man:mkisofs[8], a program that can be used to produce a data file containing an ISO 9660 file system. It has options that support various extensions, and is described below. Which tool to use to burn the CD depends on whether the CD burner is ATAPI or something else. ATAPI CD burners use `burncd` which is part of the base system. SCSI and USB CD burners should use `cdrecord` from the package:sysutils/cdrtools[] port. It is also possible to use `cdrecord` and other tools for SCSI drives on ATAPI hardware with the <>. For CD burning software with a graphical user interface, consider X-CD-Roast or K3b. These tools are available as packages or from the package:sysutils/xcdroast[] and package:sysutils/k3b[] ports. X-CD-Roast and K3b require the <> with ATAPI hardware. [[mkisofs]] === mkisofs The package:sysutils/cdrtools[] port also installs man:mkisofs[8], which produces an ISO 9660 file system that is an image of a directory tree in the UNIX(R) file system name space. The simplest usage is: [source,shell] .... # mkisofs -o imagefile.iso /path/to/tree .... This command creates an _imagefile.iso_ containing an ISO 9660 file system that is a copy of the tree at _/path/to/tree_. In the process, it maps the file names to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that have names uncharacteristic of ISO file systems. A number of options are available to overcome these restrictions. In particular, `-R` enables the Rock Ridge extensions common to UNIX(R) systems, `-J` enables Joliet extensions used by Microsoft systems, and `-hfs` can be used to create HFS file systems used by Mac OS(R). For CDs that are going to be used only on FreeBSD systems, `-U` can be used to disable all filename restrictions. When used with `-R`, it produces a file system image that is identical to the specified FreeBSD tree, though it may violate the ISO 9660 standard in a number of ways. The last option of general use is `-b`. This is used to specify the location of the boot image for use in producing an "El Torito" bootable CD. This option takes an argument which is the path to a boot image from the top of the tree being written to the CD. By default, man:mkisofs[8] creates an ISO image in "floppy disk emulation" mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size. Some boot loaders, like the one used by the FreeBSD distribution disks, do not use emulation mode. In this case, `-no-emul-boot` should be used. So, if [.filename]#/tmp/myboot# holds a bootable FreeBSD system with the boot image in [.filename]#/tmp/myboot/boot/cdboot#, this command would produce the image of an ISO 9660 file system as [.filename]#/tmp/bootable.iso#: [source,shell] .... # mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot .... If [.filename]#md# is configured in the kernel, the file system can be mounted as a memory disk with: [source,shell] .... # mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 # mount -t cd9660 /dev/md0 /mnt .... One can then verify that [.filename]#/mnt# and [.filename]#/tmp/myboot# are identical. There are many other options available for man:mkisofs[8] to fine-tune its behavior. Refer to man:mkisofs[8] for details. [[burncd]] === burncd For an ATAPI CD burner, `burncd` can be used to burn an ISO image onto a CD. `burncd` is part of the base system, installed as [.filename]#/usr/sbin/burncd#. Usage is very simple, as it has few options: [source,shell] .... # burncd -f cddevice data imagefile.iso fixate .... This command will burn a copy of _imagefile.iso_ on _cddevice_. The default device is [.filename]#/dev/acd0#. See man:burncd[8] for options to set the write speed, eject the CD after burning, and write audio data. [[cdrecord]] === cdrecord For systems without an ATAPI CD burner, `cdrecord` can be used to burn CDs. `cdrecord` is not part of the base system and must be installed from either the package:sysutils/cdrtools[] package or port. Changes to the base system can cause binary versions of this program to fail, possibly resulting in a "coaster". It is recommended to either upgrade the port when the system is upgraded, or for users crossref:cutting-edge[stable,tracking -STABLE], to upgrade the port when a new version becomes available. While `cdrecord` has many options, basic usage is simple. Burning an ISO 9660 image is done with: [source,shell] .... # cdrecord dev=device imagefile.iso .... The tricky part of using `cdrecord` is finding the `dev` to use. To find the proper setting, use `-scanbus` which might produce results like this: [source,shell] .... # cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 J"org Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * .... This lists the appropriate `dev` value for the devices on the list. Locate the CD burner, and use the three numbers separated by commas as the value for `dev`. In this case, the CRW device is 1,5,0, so the appropriate input is `dev=1,5,0`. Refer to man:cdrecord[1] for easier ways to specify this value and for information on writing audio tracks and controlling the write speed. [[duplicating-audiocds]] === Duplicating Audio CDs To duplicate an audio CD, extract the audio data from the CD to a series of files, then write these files to a blank CD. The process is slightly different for ATAPI and SCSI drives. [.procedure] .Procedure: SCSI Drives . Use `cdda2wav` to extract the audio: + [source,shell] .... % cdda2wav -vall -D2,0 -B -Owav .... . Use `cdrecord` to write the [.filename]#.wav# files: + [source,shell] .... % cdrecord -v dev=2,0 -dao -useinfo *.wav .... + Make sure that _2,0_ is set appropriately, as described in <>. [.procedure] ==== *Procedure: ATAPI Drives* [NOTE] ====== With the help of the <>, `cdda2wav` can also be used on ATAPI drives. This tool is usually a better choice for most of users, as it supports jitter correction and endianness, than the method proposed below. ====== . The ATAPI CD driver makes each track available as [.filename]#/dev/acddtnn#, where _d_ is the drive number, and _nn_ is the track number written with two decimal digits, prefixed with zero as needed. So the first track on the first disk is [.filename]#/dev/acd0t01#, the second is [.filename]#/dev/acd0t02#, the third is [.filename]#/dev/acd0t03#, and so on. + Make sure the appropriate files exist in [.filename]#/dev#. If the entries are missing, force the system to retaste the media: + [source,shell] .... # dd if=/dev/acd0 of=/dev/null count=1 .... . Extract each track using man:dd[1], making sure to specify a block size when extracting the files: + [source,shell] .... # dd if=/dev/acd0t01 of=track1.cdr bs=2352 # dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... .... . Burn the extracted files to disk using `burncd`. Specify that these are audio files, and that `burncd` should fixate the disk when finished: + [source,shell] .... # burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate .... ==== [[imaging-cd]] === Duplicating Data CDs It is possible to copy a data CD to an image file that is functionally equivalent to the image file created with man:mkisofs[8], and then use it to duplicate any data CD. The example given here assumes that the CD-ROM device is [.filename]#acd0#. Substitute the correct CD-ROM device. [source,shell] .... # dd if=/dev/acd0 of=file.iso bs=2048 .... Now that there is an image, it can be burned to CD as described above. [[mounting-cd]] === Using Data CDs It is possible to mount and read the data on a standard data CD. By default, man:mount[8] assumes that a file system is of type `ufs`. Running this command: [source,shell] .... # mount /dev/cd0 /mnt .... will generate an error about `Incorrect super block`, and will fail to mount the CD. The CD does not use the `UFS` file system, so attempts to mount it as such will fail. Instead, tell man:mount[8] that the file system is of type `ISO9660` by specifying `-t cd9660` to man:mount[8]. For example, to mount the CD-ROM device, [.filename]#/dev/cd0#, under [.filename]#/mnt#, use: [source,shell] .... # mount -t cd9660 /dev/cd0 /mnt .... Replace [.filename]#/dev/cd0# with the device name for the CD device. Also, `-t cd9660` executes man:mount_cd9660[8], meaning the above command is equivalent to: [source,shell] .... # mount_cd9660 /dev/cd0 /mnt .... While data CD-ROMs from any vendor can be mounted this way, disks with certain ISO 9660 extensions might behave oddly. For example, Joliet disks store all filenames in two-byte Unicode characters. The FreeBSD kernel does not speak Unicode, but the FreeBSD CD9660 driver is able to convert Unicode characters on the fly. If some non-English characters show up as question marks, specify the local charset with `-C`. For more information, refer to man:mount_cd9660[8]. [NOTE] ==== In order to do this character conversion with the help of `-C`, the kernel requires the [.filename]#cd9660_iconv.ko# module to be loaded. This can be done either by adding this line to [.filename]#loader.conf#: [.programlisting] .... cd9660_iconv_load="YES" .... and then rebooting the machine, or by directly loading the module with man:kldload[8]. ==== Occasionally, `Device not configured` will be displayed when trying to mount a CD-ROM. This usually means that the CD-ROM drive thinks that there is no disk in the tray, or that the drive is not visible on the bus. It can take a couple of seconds for a CD-ROM drive to realize that a media is present, so be patient. Sometimes, a SCSI CD-ROM may be missed because it did not have enough time to answer the bus reset. To resolve this, add the following option to the kernel configuration and crossref:kernelconfig[kernelconfig-building,rebuild the kernel]. [.programlisting] .... options SCSI_DELAY=15000 .... This tells the SCSI bus to pause 15 seconds during boot, to give the CD-ROM drive every possible chance to answer the bus reset. [[rawdata-cd]] === Burning Raw Data CDs It is possible to burn a file directly to CD, without creating an ISO 9660 file system. Some people do this for backup purposes. This command runs more quickly than burning a standard CD: [source,shell] .... # burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate .... In order to retrieve the data burned to such a CD, the data must be read from the raw device node: [source,shell] .... # tar xzvf /dev/acd1 .... This type of disk can not be mounted as a normal CD-ROM and the data cannot be read under any operating system except FreeBSD. In order to mount the CD, or to share the data with another operating system, man:mkisofs[8] must be used as described above. [[atapicam]] === Using the ATAPI/CAM Driver This driver allows ATAPI devices, such as CD/DVD drives, to be accessed through the SCSI subsystem, and so allows the use of applications like package:sysutils/cdrdao[] or man:cdrecord[1]. To use this driver, add the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... atapicam_load="YES" .... then, reboot the system. [NOTE] ==== Users who prefer to statically compile man:atapicam[4] support into the kernel, should add this line to the kernel configuration file: [.programlisting] .... device atapicam .... Ensure the following lines are still in the kernel configuration file: [.programlisting] .... device ata device scbus device cd device pass .... Then rebuild, install the new kernel, and reboot the machine. ==== During the boot process, the burner should show up, like so: [source,shell] .... acd0: CD-RW at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed .... The drive can now be accessed via the [.filename]#/dev/cd0# device name. For example, to mount a CD-ROM on [.filename]#/mnt#, type the following: [source,shell] .... # mount -t cd9660 /dev/cd0 /mnt .... As `root`, run the following command to get the SCSI address of the burner: [source,shell] .... # camcontrol devlist at scbus1 target 0 lun 0 (pass0,cd0) .... In this example, `1,0,0` is the SCSI address to use with man:cdrecord[1] and other SCSI applications. For more information about ATAPI/CAM and SCSI system, refer to man:atapicam[4] and man:cam[4]. [[creating-dvds]] == Creating and Using DVD Media === Introduction Compared to the CD, the DVD is the next generation of optical media storage technology. The DVD can hold more data than any CD and is the standard for video publishing. Five physical recordable formats can be defined for a recordable DVD: * DVD-R: This was the first DVD recordable format available. The DVD-R standard is defined by the http://www.dvdforum.com/forum.shtml[DVD Forum]. This format is write once. * DVD-RW: This is the rewritable version of the DVD-R standard. A DVD-RW can be rewritten about 1000 times. * DVD-RAM: This is a rewritable format which can be seen as a removable hard drive. However, this media is not compatible with most DVD-ROM drives and DVD-Video players as only a few DVD writers support the DVD-RAM format. Refer to <> for more information on DVD-RAM use. * DVD+RW: This is a rewritable format defined by the http://www.dvdrw.com/[DVD+RW Alliance]. A DVD+RW can be rewritten about 1000 times. * DVD+R: This format is the write once variation of the DVD+RW format. A single layer recordable DVD can hold up to 4,700,000,000 bytes which is actually 4.38 GB or 4485 MB as 1 kilobyte is 1024 bytes. [NOTE] ==== A distinction must be made between the physical media and the application. For example, a DVD-Video is a specific file layout that can be written on any recordable DVD physical media such as DVD-R, DVD+R, or DVD-RW. Before choosing the type of media, ensure that both the burner and the DVD-Video player are compatible with the media under consideration. ==== === Configuration To perform DVD recording, use man:growisofs[1]. This command is part of the package:sysutils/dvd+rw-tools[] utilities which support all DVD media types. These tools use the SCSI subsystem to access the devices, therefore <> must be loaded or statically compiled into the kernel. This support is not needed if the burner uses the USB interface. Refer to <> for more details on USB device configuration. DMA access must also be enabled for ATAPI devices, by adding the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... hw.ata.atapi_dma="1" .... Before attempting to use dvd+rw-tools, consult the http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html[Hardware Compatibility Notes]. [NOTE] ==== For a graphical user interface, consider using package:sysutils/k3b[] which provides a user friendly interface to man:growisofs[1] and many other burning tools. ==== === Burning Data DVDs Since man:growisofs[1] is a front-end to <>, it will invoke man:mkisofs[8] to create the file system layout and perform the write on the DVD. This means that an image of the data does not need to be created before the burning process. To burn to a DVD+R or a DVD-R the data in [.filename]#/path/to/data#, use the following command: [source,shell] .... # growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data .... In this example, `-J -R` is passed to man:mkisofs[8] to create an ISO 9660 file system with Joliet and Rock Ridge extensions. Refer to man:mkisofs[8] for more details. For the initial session recording, `-Z` is used for both single and multiple sessions. Replace _/dev/cd0_, with the name of the DVD device. Using `-dvd-compat` indicates that the disk will be closed and that the recording will be unappendable. This should also provide better media compatibility with DVD-ROM drives. To burn a pre-mastered image, such as _imagefile.iso_, use: [source,shell] .... # growisofs -dvd-compat -Z /dev/cd0=imagefile.iso .... The write speed should be detected and automatically set according to the media and the drive being used. To force the write speed, use `-speed=`. Refer to man:growisofs[1] for example usage. [NOTE] ==== In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid filesystem must be created by passing `-udf -iso-level 3` to man:mkisofs[8] and all related programs, such as man:growisofs[1]. This is required only when creating an ISO image file or when writing files directly to a disk. Since a disk created this way must be mounted as an UDF filesystem with man:mount_udf[8], it will be usable only on an UDF aware operating system. Otherwise it will look as if it contains corrupted files. To create this type of ISO file: [source,shell] .... % mkisofs -R -J -udf -iso-level 3 -o imagefile.iso /path/to/data .... To burn files directly to a disk: [source,shell] .... # growisofs -dvd-compat -udf -iso-level 3 -Z /dev/cd0 -J -R /path/to/data .... When an ISO image already contains large files, no additional options are required for man:growisofs[1] to burn that image on a disk. Be sure to use an up-to-date version of package:sysutils/cdrtools[], which contains man:mkisofs[8], as an older version may not contain large files support. If the latest version does not work, install package:sysutils/cdrtools-devel[] and read its man:mkisofs[8]. ==== === Burning a DVD-Video A DVD-Video is a specific file layout based on the ISO 9660 and micro-UDF (M-UDF) specifications. Since DVD-Video presents a specific data structure hierarchy, a particular program such as package:multimedia/dvdauthor[] is needed to author the DVD. If an image of the DVD-Video file system already exists, it can be burned in the same way as any other image. If `dvdauthor` was used to make the DVD and the result is in [.filename]#/path/to/video#, the following command should be used to burn the DVD-Video: [source,shell] .... # growisofs -Z /dev/cd0 -dvd-video /path/to/video .... `-dvd-video` is passed to man:mkisofs[8] to instruct it to create a DVD-Video file system layout. This option implies the `-dvd-compat` man:growisofs[1] option. === Using a DVD+RW Unlike CD-RW, a virgin DVD+RW needs to be formatted before first use. It is _recommended_ to let man:growisofs[1] take care of this automatically whenever appropriate. However, it is possible to use `dvd+rw-format` to format the DVD+RW: [source,shell] .... # dvd+rw-format /dev/cd0 .... Only perform this operation once and keep in mind that only virgin DVD+RW medias need to be formatted. Once formatted, the DVD+RW can be burned as usual. To burn a totally new file system and not just append some data onto a DVD+RW, the media does not need to be blanked first. Instead, write over the previous recording like this: [source,shell] .... # growisofs -Z /dev/cd0 -J -R /path/to/newdata .... The DVD+RW format supports appending data to a previous recording. This operation consists of merging a new session to the existing one as it is not considered to be multi-session writing. man:growisofs[1] will _grow_ the ISO 9660 file system present on the media. For example, to append data to a DVD+RW, use the following: [source,shell] .... # growisofs -M /dev/cd0 -J -R /path/to/nextdata .... The same man:mkisofs[8] options used to burn the initial session should be used during next writes. [NOTE] ==== Use `-dvd-compat` for better media compatibility with DVD-ROM drives. When using DVD+RW, this option will not prevent the addition of data. ==== To blank the media, use: [source,shell] .... # growisofs -Z /dev/cd0=/dev/zero .... === Using a DVD-RW A DVD-RW accepts two disc formats: incremental sequential and restricted overwrite. By default, DVD-RW discs are in sequential format. A virgin DVD-RW can be directly written without being formatted. However, a non-virgin DVD-RW in sequential format needs to be blanked before writing a new initial session. To blank a DVD-RW in sequential mode: [source,shell] .... # dvd+rw-format -blank=full /dev/cd0 .... [NOTE] ==== A full blanking using `-blank=full` will take about one hour on a 1x media. A fast blanking can be performed using `-blank`, if the DVD-RW will be recorded in Disk-At-Once (DAO) mode. To burn the DVD-RW in DAO mode, use the command: [source,shell] .... # growisofs -use-the-force-luke=dao -Z /dev/cd0=imagefile.iso .... Since man:growisofs[1] automatically attempts to detect fast blanked media and engage DAO write, `-use-the-force-luke=dao` should not be required. One should instead use restricted overwrite mode with any DVD-RW as this format is more flexible than the default of incremental sequential. ==== To write data on a sequential DVD-RW, use the same instructions as for the other DVD formats: [source,shell] .... # growisofs -Z /dev/cd0 -J -R /path/to/data .... To append some data to a previous recording, use `-M` with man:growisofs[1]. However, if data is appended on a DVD-RW in incremental sequential mode, a new session will be created on the disc and the result will be a multi-session disc. A DVD-RW in restricted overwrite format does not need to be blanked before a new initial session. Instead, overwrite the disc with `-Z`. It is also possible to grow an existing ISO 9660 file system written on the disc with `-M`. The result will be a one-session DVD. To put a DVD-RW in restricted overwrite format, the following command must be used: [source,shell] .... # dvd+rw-format /dev/cd0 .... To change back to sequential format, use: [source,shell] .... # dvd+rw-format -blank=full /dev/cd0 .... === Multi-Session Few DVD-ROM drives support multi-session DVDs and most of the time only read the first session. DVD+R, DVD-R and DVD-RW in sequential format can accept multiple sessions. The notion of multiple sessions does not exist for the DVD+RW and the DVD-RW restricted overwrite formats. Using the following command after an initial non-closed session on a DVD+R, DVD-R, or DVD-RW in sequential format, will add a new session to the disc: [source,shell] .... # growisofs -M /dev/cd0 -J -R /path/to/nextdata .... Using this command with a DVD+RW or a DVD-RW in restricted overwrite mode will append data while merging the new session to the existing one. The result will be a single-session disc. Use this method to add data after an initial write on these types of media. [NOTE] ==== Since some space on the media is used between each session to mark the end and start of sessions, one should add sessions with a large amount of data to optimize media space. The number of sessions is limited to 154 for a DVD+R, about 2000 for a DVD-R, and 127 for a DVD+R Double Layer. ==== === For More Information To obtain more information about a DVD, use `dvd+rw-mediainfo /dev/cd0` while the disc in the specified drive. More information about dvd+rw-tools can be found in man:growisofs[1], on the http://fy.chalmers.se/~appro/linux/DVD+RW/[dvd+rw-tools web site], and in the http://lists.debian.org/cdwrite/[cdwrite mailing list] archives. [NOTE] ==== When creating a problem report related to the use of dvd+rw-tools, always include the output of `dvd+rw-mediainfo`. ==== [[creating-dvd-ram]] === Using a DVD-RAM ==== Configuration DVD-RAM writers can use either a SCSI or ATAPI interface. For ATAPI devices, DMA access has to be enabled by adding the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... hw.ata.atapi_dma="1" .... ==== Preparing the Media A DVD-RAM can be seen as a removable hard drive. Like any other hard drive, the DVD-RAM must be formatted before it can be used. In this example, the whole disk space will be formatted with a standard UFS2 file system: [source,shell] .... # dd if=/dev/zero of=/dev/acd0 bs=2k count=1 # bsdlabel -Bw acd0 # newfs /dev/acd0 .... The DVD device, [.filename]#acd0#, must be changed according to the configuration. ==== Using the Media Once the DVD-RAM has been formatted, it can be mounted as a normal hard drive: [source,shell] .... # mount /dev/acd0 /mnt .... Once mounted, the DVD-RAM will be both readable and writeable. [[floppies]] == Creating and Using Floppy Disks Storing data on floppy disks is sometimes useful, for example when one does not have any other removable storage media or when one needs to transfer small amounts of data to another computer. This section explains how to use floppy disks in FreeBSD. It covers formatting and usage of 3.5inch DOS floppies, but the concepts are similar for other floppy disk formats. === Formatting Floppies ==== The Device Floppy disks are accessed through entries in [.filename]#/dev#, just like other devices. To access the raw floppy disk, simply use [.filename]#/dev/fdN#. ==== Formatting A floppy disk needs to be low-level formatted before it can be used. This is usually done by the vendor, but formatting is a good way to check media integrity. Although it is possible to force other disk sizes, 1440kB is what most floppy disks are designed for. To low-level format the floppy disk, use man:fdformat[1]. This utility expects the device name as an argument. Make note of any error messages, as these can help determine if the disk is good or bad. ===== Formatting Floppy Disks To format the floppy, insert a new 3.5inch floppy disk into the first floppy drive and issue: [source,shell] .... # /usr/sbin/fdformat -f 1440 /dev/fd0 .... === The Disk Label After low-level formatting the disk, a disk label needs to placed on it. This disk label will be destroyed later, but it is needed by the system to determine the size of the disk and its geometry. The new disk label will take over the whole disk and will contain all the proper information about the geometry of the floppy. The geometry values for the disk label are listed in [.filename]#/etc/disktab#. To write the disk label, use man:bsdlabel[8]: [source,shell] .... # /sbin/bsdlabel -B -w /dev/fd0 fd1440 .... === The File System The floppy is now ready to be high-level formatted. This will place a new file system on it so that FreeBSD can read and write to the disk. Since creating the new file system destroys the disk label, the disk label needs to be recreated whenever the disk is reformatted. The floppy's file system can be either UFS or FAT. FAT is generally a better choice for floppies. To put a new file system on the floppy, issue: [source,shell] .... # /sbin/newfs_msdos /dev/fd0 .... The disk is now ready for use. === Using the Floppy To use the floppy, mount it with man:mount_msdosfs[8]. One can also use package:emulators/mtools[] from the Ports Collection. [[backups-tapebackups]] == Creating and Using Data Tapes Tape technology has continued to evolve but is less likely to be used in a modern system. Modern backup systems tend to use off site combined with local removable disk drive technologies. Still, FreeBSD will support any tape drive that uses SCSI, such as LTO and older devices such as DAT. There is limited support for SATA and USB tape drives. [[tapes-sa0]] === Serial Access with man:sa[4] FreeBSD uses the man:sa[4] driver, providing [.filename]#/dev/sa0#, [.filename]#/dev/nsa0#, and [.filename]#/dev/esa0#. In normal use, only [.filename]#/dev/sa0# is needed. [.filename]#/dev/nsa0# is the same physical drive as [.filename]#/dev/sa0# but does not rewind the tape after writing a file. This allows writing more than one file to a tape. Using [.filename]#/dev/esa0# ejects the tape after the device is closed, if applicable. === Controlling the Tape Drive with man:mt[1] man:mt[1] is the FreeBSD utility for controlling other operations of the tape drive, such as seeking through files on a tape or writing tape control marks to the tape. For example, the first three files on a tape can be preserved by skipping past them before writing a new file: [source,shell] .... # mt -f /dev/nsa0 fsf 3 .... === Using man:tar[1] to Read and Write Tape Backups An example of writing a single file to tape using man:tar[1]: [source,shell] .... # tar cvf /dev/sa0 file .... Recovering files from a man:tar[1] archive on tape into the current directory: [source,shell] .... # tar xvf /dev/sa0 .... === Using man:dump[8] and man:restore[8] to Create and Restore Backups A simple backup of [.filename]#/usr# with man:dump[8]: [source,shell] .... # dump -0aL -b64 -f /dev/nsa0 /usr .... Interactively restoring files from a man:dump[8] file on tape into the current directory: [source,shell] .... # restore -i -f /dev/nsa0 .... === Other Tape Software Higher-level programs are available to simplify tape backup. The most popular are Amanda and Bacula. These programs aim to make backups easier and more convenient, or to automate complex backups of multiple machines. The Ports Collection contains both these and other tape utility applications. [[backup-strategies]] == Backup Strategies The first requirement in devising a backup plan is to make sure that all of the following problems are covered: * Disk failure. * Accidental file deletion. * Random file corruption. * Complete machine destruction, say by fire, including destruction of any on-site backups. Some systems will be best served by having each of these problems covered by a completely different technique. Except for strictly personal systems with low-value data, it is unlikely that one technique will cover all of them. Some possible techniques include: * Archives of the whole system, backed up onto permanent, off-site media. This provides protection against all of the problems listed above, but is slow and inconvenient to restore from. Copies of the backups can be stored on site or online, but there will still be inconveniences in restoring files, especially for non-privileged users. * Filesystem snapshots, which are really only helpful in the accidental file deletion scenario, but can be _very_ helpful in that case, as well as quick and easy to deal with. * Copies of whole file systems or disks which can be created with a periodic package:net/rsync[] of the whole machine. This is generally most useful in networks with unique requirements. For general protection against disk failure, this is usually inferior to RAID. For restoring accidentally deleted files, it can be comparable to UFS snapshots. * RAID, which minimizes or avoids downtime when a disk fails at the expense of having to deal with disk failures more often, because there are more disks, albeit at a much lower urgency. * Checking fingerprints of files using man:mtree[8]. Although this is not a backup, this technique indicates when one needs to resort to backups. This is particularly important for offline backups, and should be checked periodically. It is quite easy to come up with more techniques, many of them variations on the ones listed above. Specialized requirements usually lead to specialized techniques. For example, backing up a live database usually requires a method particular to the database software as an intermediate step. The important thing is to know which dangers should be protected against, and how each will be handled. [[backup-basics]] == Backup Basics The major backup programs built into FreeBSD are man:dump[8], man:tar[1], man:cpio[1], and man:pax[1]. === Dump and Restore The traditional UNIX(R) backup programs are `dump` and `restore`. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the file systems. Unlike other backup software, `dump` backs up an entire file system on a device. It is unable to backup only part of a file system or a directory tree that spans more than one file system. `dump` does not write files and directories, but rather writes the raw data blocks that comprise files and directories. When used to extract data, `restore` stores temporary files in [.filename]#/tmp/# by default. When using a recovery disk with a small [.filename]#/tmp#, set `TMPDIR` to a directory with more free space in order for the restore to succeed. [NOTE] ==== If `dump` is used on the root directory, it will not back up [.filename]#/home#, [.filename]#/usr# or many other directories since these are typically mount points for other file systems or symbolic links into those file systems. ==== `dump` has quirks that remain from its early days in Version 6 of AT&T UNIX(R),circa 1975. The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. It is also possible to backup data across the network to a tape drive attached to another computer with `rdump` and `rrestore`. Both programs rely upon man:rcmd[3] and man:ruserok[3] to access the remote tape drive. Therefore, the user performing the backup must be listed in [.filename]#.rhosts# on the remote computer. The arguments to `rdump` and `rrestore` must be suitable to use on the remote computer. For example, to `rdump` from a FreeBSD computer to an Exabyte tape drive connected to a host called `komodo`, use: [source,shell] .... # /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 .... There are security implications to allowing [.filename]#.rhosts# authentication, so use with caution. It is also possible to use `dump` and `restore` in a more secure fashion over `ssh`. .Using `dump` over ssh [example] ==== [source,shell] .... # /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \ targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz .... ==== Or, use the built-in `RSH`: .Using `dump` over ssh with `RSH` Set [example] ==== [source,shell] .... # env RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr .... ==== === `tar` man:tar[1] also dates back to Version 6 of AT&T UNIX(R), circa 1975. `tar` operates in cooperation with the file system and writes files and directories to tape. `tar` does not support the full range of options that are available from man:cpio[1], but it does not require the unusual command pipeline that `cpio` uses. To `tar` to an Exabyte tape drive connected to a host called `komodo`: [source,shell] .... # tar cf - . | rsh komodo dd of=tape-device obs=20b .... When backing up over an insecure network, instead use `ssh`. === `cpio` man:cpio[1] is the original UNIX(R) file interchange tape program for magnetic media. `cpio` includes options to perform byte-swapping, write a number of different archive formats, and pipe the data to other programs. This last feature makes `cpio` an excellent choice for installation media. `cpio` does not know how to walk the directory tree and a list of files must be provided through [.filename]#stdin#. Since `cpio` does not support backups across the network, use a pipeline and `ssh` to send the data to a remote tape drive. [source,shell] .... # for f in directory_list; do # find $f >> backup.list # done # cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device" .... Where _directory_list_ is the list of directories to back up, _user_@_host_ is the user/hostname combination that will be performing the backups, and _backup_device_ is where the backups should be written to, such as [.filename]#/dev/nsa0#). === `pax` man:pax[1] is the IEEE/POSIX(R) answer to `tar` and `cpio`. Over the years the various versions of `tar` and `cpio` have become slightly incompatible. So rather than fight it out to fully standardize them, POSIX(R) created a new archive utility. `pax` attempts to read and write many of the various `cpio` and `tar` formats, plus new formats of its own. Its command set more resembles `cpio` than `tar`. [[backups-programs-amanda]] === Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and a network connection to the Amanda server. A common problem at sites with a number of large disks is that the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem by using a "holding disk" to backup several file systems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the file systems listed in Amanda's configuration file. The "archive set" also contains nightly incremental, or differential, backups of all the file systems. Restoring a damaged file system requires the most recent full backup and the incremental backups. The configuration file provides fine grained control of backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is not installed by but is available as either a port or package. === Do Nothing "Do nothing" is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and data is worth little to nothing, then "Do nothing" is the most suitable backup program for the computer. But beware, FreeBSD is a useful tool and over time it can be used to create a valuable collection of files. "Do nothing" is the correct backup method for [.filename]#/usr/obj# and other directory trees that can be exactly recreated by the computer. An example is the files that comprise the HTML or PostScript(R) version of this Handbook. These document formats have been created from XML input files. Creating backups of the HTML or PostScript(R) files is not necessary if the XML files are backed up regularly. === Which Backup Program Is Best? man:dump[8] _Period._ Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of UNIX(R) file systems is `dump`. Elizabeth created file systems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of those file systems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See http://www.coredumps.de/doc/dump/zwicky/testdump.doc.html[torture-testing Backup and Archive Programs]. === Emergency Restore Procedure ==== Before the Disaster There are four steps which should be performed in preparation for any disaster that may occur. First, print the bsdlabel of each disk using a command such as `bsdlabel da0 | lpr`. Also print a copy of [.filename]#/etc/fstab# and all boot messages. Second, burn a "livefs" CD. This CD contains support for booting into a FreeBSD "livefs" rescue mode, allowing the user to perform many tasks like running man:dump[8], man:restore[8], man:fdisk[8], man:bsdlabel[8], man:newfs[8], man:mount[8], and more. The livefs CD image for FreeBSD/i386 {rel112-current}-RELEASE is available from link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/{rel112-current}/FreeBSD-{rel112-current}-RELEASE-i386-livefs.iso[ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/{rel112-current}/FreeBSD-{rel112-current}-RELEASE-i386-livefs.iso]. [NOTE] ==== Livefs CD images are not available for FreeBSD {rel120-current}-RELEASE and later. In addition to the CD-ROM installation images, flash drive installation images may be used to recover a system. The "memstick" image for FreeBSD/i386 {rel120-current}-RELEASE is available from link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/i386/ISO-IMAGES/{rel120-current}/FreeBSD-{rel120-current}-RELEASE-i386-memstick.img[ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/i386/ISO-IMAGES/{rel120-current}/FreeBSD-{rel120-current}-RELEASE-i386-memstick.img]. ==== Third, create backup tapes regularly. Any changes that made after the last backup may be irretrievably lost. Write-protect the backup media. Fourth, test the "livefs" CD and the backups. Make notes of the procedure. Store these notes with the CD, the printouts, and the backups. These notes may prevent the inadvertent destruction of the backups while under the stress of performing an emergency recovery. For an added measure of security, store an extra "livefs" CD and the latest backup at a remote location, where a remote location is _not_ the basement of the same building. A remote location should be physically separated from the computers and disk drives by a significant distance. ==== After the Disaster First, determine if the hardware survived. Thanks to regular, off-site backups, there is no need to worry about the software. If the hardware has been damaged, the parts should be replaced before attempting to use the computer. If the hardware is okay, insert the "livefs" CD and boot the computer. The original install menu will be displayed on the screen. Select the correct country, then choose [.guimenuitem]#Fixit -- Repair mode with CD-ROM/DVD/floppy or start a shell.# then select [.guimenuitem]#CD-ROM/DVD -- Use the live filesystem CD-ROM/DVD#. `restore` and the other needed programs are located in [.filename]#/mnt2/rescue#. Recover each file system separately. Try to `mount` the root partition of the first disk using `mount /dev/da0a /mnt`. If the bsdlabel was damaged, use `bsdlabel` to re-partition and label the disk to match the label that was printed and saved. Use `newfs` to re-create the file systems. Re-mount the root partition of the disk read-write using `mount -u -o rw /mnt`. Use the backups to recover the data for this file system. Unmount the file system with `umount /mnt`. Repeat for each file system that was damaged. Once the system is running, backup the data onto new media as whatever caused the crash or data loss may strike again. Another hour spent now may save further distress later. [[disks-virtual]] == Network, Memory, and File-Backed File Systems In addition to physical disks such as floppies, CDs, and hard drives, FreeBSD also supports _virtual disks_. These include network file systems such as the crossref:network-servers[network-nfs,Network File System] and Coda, memory-based file systems, and file-backed file systems. According to the FreeBSD version, the tools used for the creation and use of file-backed and memory-based file systems differ. [NOTE] ==== Use man:devfs[5] to allocate device nodes transparently for the user. ==== [[disks-mdconfig]] === File-Backed File System man:mdconfig[8] is used to configure and enable memory disks, man:md[4], under FreeBSD. To use man:mdconfig[8], man:md[4] must be first loaded. When using a custom kernel configuration file, ensure it includes this line: [.programlisting] .... device md .... man:mdconfig[8] supports several types of memory backed virtual disks: memory disks allocated with man:malloc[9] and memory disks using a file or swap space as backing. One possible use is the mounting of CD images. To mount an existing file system image: .Using `mdconfig` to Mount an Existing File System Image [example] ==== [source,shell] .... # mdconfig -a -t vnode -f diskimage -u 0 # mount /dev/md0 /mnt .... ==== To create a new file system image with man:mdconfig[8]: .Creating a New File-Backed Disk with `mdconfig` [example] ==== [source,shell] .... # dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out # mdconfig -a -t vnode -f newimage -u 0 # bsdlabel -w md0 auto # newfs md0a /dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2720, 5280, 7840 # mount /dev/md0a /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt .... ==== If unit number is not specified with `-u`, man:mdconfig[8] uses the man:md[4] automatic allocation to select an unused device. The name of the allocated unit will be output to stdout, such as [.filename]#md4#. Refer to man:mdconfig[8] for more details about. While man:mdconfig[8] is useful, it takes several command lines to create a file-backed file system. FreeBSD also comes with man:mdmfs[8] which automatically configures a man:md[4] disk using man:mdconfig[8], puts a UFS file system on it using man:newfs[8], and mounts it using man:mount[8]. For example, to create and mount the same file system image as above, type the following: .Configure and Mount a File-Backed Disk with `mdmfs` [example] ==== [source,shell] .... # dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out # mdmfs -F newimage -s 5m md0 /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4718 4 4338 0% /mnt .... ==== When `md` is used without a unit number, man:mdmfs[8] uses the man:md[4] auto-unit feature to automatically select an unused device. For more details about man:mdmfs[8], refer to its manual page. [[disks-md-freebsd5]] === Memory-Based File System For a memory-based file system, "swap backing" should normally be used. This does not mean that the memory disk will be swapped out to disk by default, but rather that the memory disk will be allocated from a memory pool which can be swapped out to disk if needed. It is also possible to create memory-based disks which are man:malloc[9] backed, but using large malloc backed memory disks can result in a system panic if the kernel runs out of memory. .Creating a New Memory-Based Disk with `mdconfig` [example] ==== [source,shell] .... # mdconfig -a -t swap -s 5m -u 1 # newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2752, 5344, 7936 # mount /dev/md1 /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt .... ==== .Creating a New Memory-Based Disk with `mdmfs` [example] ==== [source,shell] .... # mdmfs -s 5m md2 /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt .... ==== === Detaching a Memory Disk from the System When a memory-based or file-based file system is no longer in use, its resources should be released back to the system. First, unmount the file system, then use man:mdconfig[8] to detach the disk from the system and release the resources. For example, to detach and free all resources used by [.filename]#/dev/md4#: [source,shell] .... # mdconfig -d -u 4 .... It is possible to list information about configured man:md[4] devices by running `mdconfig -l`. [[snapshots]] == File System Snapshots FreeBSD offers a feature in conjunction with crossref:cutting-edge[soft-updates,Soft Updates]: file system snapshots. UFS snapshots allow a user to create images of specified file systems, and treat them as a file. Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system. Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots. When a snapshot is no longer required, it can be removed using man:rm[1]. While snapshots may be removed in any order, all the used space may not be acquired because another snapshot will possibly claim some of the released blocks. The un-alterable `snapshot` file flag is set by man:mksnap_ffs[8] after initial creation of a snapshot file. man:unlink[1] makes an exception for snapshot files since it allows them to be removed. Snapshots are created using man:mount[8]. To place a snapshot of [.filename]#/var# in the file [.filename]#/var/snapshot/snap#, use the following command: [source,shell] .... # mount -u -o snapshot /var/snapshot/snap /var .... Alternatively, use man:mksnap_ffs[8] to create the snapshot: [source,shell] .... # mksnap_ffs /var /var/snapshot/snap .... One can find snapshot files on a file system, such as [.filename]#/var#, using man:find[1]: [source,shell] .... # find /var -flags snapshot .... Once a snapshot has been created, it has several uses: * Some administrators will use a snapshot file for backup purposes, because the snapshot can be transferred to CDs or tape. * The file system integrity checker, man:fsck[8], may be run on the snapshot. Assuming that the file system was clean when it was mounted, this should always provide a clean and unchanging result. * Running man:dump[8] on the snapshot will produce a dump file that is consistent with the file system and the timestamp of the snapshot. man:dump[8] can also take a snapshot, create a dump image, and then remove the snapshot in one command by using `-L`. * The snapshot can be mounted as a frozen image of the file system. To man:mount[8] the snapshot [.filename]#/var/snapshot/snap# run: + [source,shell] .... # mdconfig -a -t vnode -f /var/snapshot/snap -u 4 # mount -r /dev/md4 /mnt .... The frozen [.filename]#/var# is now available through [.filename]#/mnt#. Everything will initially be in the same state it was during the snapshot creation time. The only exception is that any earlier snapshots will appear as zero length files. To unmount the snapshot, use: [source,shell] .... # umount /mnt # mdconfig -d -u 4 .... For more information about `softupdates` and file system snapshots, including technical papers, visit Marshall Kirk McKusick's website at http://www.mckusick.com/[http://www.mckusick.com/]. [[quotas]] == File System Quotas Quotas are an optional feature of the operating system that can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This prevents one user or group of users from consuming all of the available disk space. === Configuring the System to Enable Disk Quotas Before using disk quotas, quota support must be added to the kernel by adding the following line to the kernel configuration file: [.programlisting] .... options QUOTA .... Before FreeBSD 9.2, the [.filename]#GENERIC# kernel usually did not include this option. `sysctl kern.features.ufs_quota` can be used to test whether the current kernel supports quotas. If the option is not present, a custom kernel must be compiled. Refer to crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel] for more information on kernel configuration. Next, enable disk quotas in [.filename]#/etc/rc.conf#: [.programlisting] .... quota_enable="YES" .... For finer control over quota startup, an additional configuration variable is available. Normally on bootup, the quota integrity of each file system is checked by man:quotacheck[8]. This program insures that the data in the quota database properly reflects the data on the file system. This is a time consuming process that will significantly affect the time the system takes to boot. To skip this step, add this variable to [.filename]#/etc/rc.conf#: [.programlisting] .... check_quotas="NO" .... Finally, edit [.filename]#/etc/fstab# to enable disk quotas on a per-file system basis. This is when user or group quotas can be enabled on the file systems. To enable per-user quotas on a file system, add `userquota` to the options field in the [.filename]#/etc/fstab# entry for the file system to enable quotas on. For example: [.programlisting] .... /dev/da1s2g /home ufs rw,userquota 1 2 .... To enable group quotas, instead use `groupquota`. To enable both user and group quotas, change the entry as follows: [.programlisting] .... /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 .... By default, the quota files are stored in the root directory of the file system as [.filename]#quota.user# and [.filename]#quota.group#. Refer to man:fstab[5] for more information. Even though an alternate location for the quota files can be specified, this is not recommended because the various quota utilities do not seem to handle this properly. Once the configuration is complete, reboot the system with the new kernel. [.filename]#/etc/rc# will automatically run the appropriate commands to create the initial quota files for all of the quotas enabled in [.filename]#/etc/fstab#. There is no need to manually create any zero length quota files. In the normal course of operations, there should be no need to manually run man:quotacheck[8], man:quotaon[8], or man:quotaoff[8]. However, one should read their manual pages to be familiar with their operation. === Setting Quota Limits Once the system has been configured to enable quotas, verify they really are enabled by running: [source,shell] .... # quota -v .... There should be a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. The system is now ready to be assigned quota limits with man:edquota[8]. Several options are available to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. Allocations can be limited based on disk space (block quotas), number of files (inode quotas), or a combination of both. Each limits is further broken down into two categories: hard and soft limits. A hard limit may not be exceeded. Once a user reaches a hard limit, no further allocations can be made on that file system by that user. For example, if the user has a hard limit of 500 kbytes on a file system and is currently using 490 kbytes, the user can only allocate an additional 10 kbytes. Attempting to allocate an additional 11 kbytes will fail. Soft limits can be exceeded for a limited amount of time, known as the grace period, which is one week by default. If a user stays over their limit longer than the grace period, the soft limit turns into a hard limit and no further allocations are allowed. When the user drops back below the soft limit, the grace period is reset. The following is an example output from man:edquota[8]. When man:edquota[8] is invoked, the editor specified by `EDITOR` is opened in order to edit the quota limits. The default editor is set to vi. [source,shell] .... # edquota -u test .... [.programlisting] .... Quotas for user test: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: kbytes in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) .... There are normally two lines for each file system that has quotas enabled. One line represents the block limits and the other represents the inode limits. Change the value to modify the quota limit. For example, to raise this user's block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: [.programlisting] .... /usr: kbytes in use: 65, limits (soft = 50, hard = 75) .... to: [.programlisting] .... /usr: kbytes in use: 65, limits (soft = 500, hard = 600) .... The new quota limits take affect upon exiting the editor. Sometimes it is desirable to set quota limits on a range of UIDs. This can be done by passing `-p` to man:edquota[8]. First, assign the desired quota limit to a user, then run `edquota -p protouser startuid-enduid`. For example, if `test` has the desired quota limits, the following command will duplicate those quota limits for UIDs 10,000 through 19,999: [source,shell] .... # edquota -p test 10000-19999 .... For more information, refer to man:edquota[8]. === Checking Quota Limits and Disk Usage Either man:quota[1] or man:repquota[8] can be used to check quota limits and disk usage. To check individual user or group quotas and disk usage, use man:quota[1]. A user may only examine their own quota and the quota of a group they are a member of. Only the superuser may view all user and group quotas. To get a summary of all quotas and disk usage for file systems with quotas enabled, use man:repquota[8]. The following is sample output from `quota -v` for a user that has quota limits on two file systems. [.programlisting] .... Disk quotas for user test (uid 1002): Filesystem usage quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 .... In this example, the user is currently 15 kbytes over the soft limit of 50 kbytes on [.filename]#/usr# and has 5 days of grace period left. The asterisk `*` indicates that the user is currently over the quota limit. Normally, file systems that the user is not using any disk space on will not show in the output of man:quota[1], even if the user has a quota limit assigned for that file system. Use `-v` to display those file systems, such as [.filename]#/usr/var# in the above example. === Quotas over NFS Quotas are enforced by the quota subsystem on the NFS server. The man:rpc.rquotad[8] daemon makes quota information available to man:quota[1] on NFS clients, allowing users on those machines to see their quota statistics. Enable `rpc.rquotad` in [.filename]#/etc/inetd.conf# like so: [.programlisting] .... rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad .... Now restart `inetd`: [source,shell] .... # service inetd restart .... [[disks-encrypting]] == Encrypting Disk Partitions FreeBSD offers excellent online protections against unauthorized data access. File permissions and crossref:mac[mac,Mandatory Access Control] (MAC) help prevent unauthorized users from accessing data while the operating system is active and the computer is powered up. However, the permissions enforced by the operating system are irrelevant if an attacker has physical access to a computer and can move the computer's hard drive to another system to copy and analyze the data. Regardless of how an attacker may have come into possession of a hard drive or powered-down computer, both the GEOM Based Disk Encryption (`gbde`) and `geli` cryptographic subsystems in FreeBSD are able to protect the data on the computer's file systems against even highly-motivated attackers with significant resources. Unlike cumbersome encryption methods that encrypt only individual files, `gbde` and `geli` transparently encrypt entire file systems. No cleartext ever touches the hard drive's platter. === Disk Encryption with gbde [.procedure] . Configuring gbde requires superuser privileges. + [source,shell] .... % su - Password: .... . If using a custom kernel configuration file, ensure it contains this line: + `options GEOM_BDE` + If the kernel already contains this support, use `kldload` to load man:gbde[4]: + [source,shell] .... # kldload geom_bde .... ==== Preparing the Encrypted Hard Drive The following example demonstrates adding a new hard drive to a system that will hold a single encrypted partition. This partition will be mounted as [.filename]#/private#. gbde can also be used to encrypt [.filename]#/home# and [.filename]#/var/mail#, but this requires more complex instructions which exceed the scope of this introduction. [.procedure] . Add the New Hard Drive + Install the new drive to the system as explained in <>. For the purposes of this example, a new hard drive partition has been added as [.filename]#/dev/ad4s1c# and [.filename]#/dev/ad0s1*# represents the existing standard FreeBSD partitions. + [source,shell] .... # ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 .... . Create a Directory to Hold `gbde` Lock Files + [source,shell] .... # mkdir /etc/gbde .... + The gbde lock file contains information that gbde requires to access encrypted partitions. Without access to the lock file, gbde will not be able to decrypt the data contained in the encrypted partition without significant manual intervention which is not supported by the software. Each encrypted partition uses a separate lock file. . Initialize the `gbde` Partition + A gbde partition must be initialized before it can be used. This initialization needs to be performed only once: + [source,shell] .... # gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock .... + man:gbde[8] will open the default editor, in order to set various configuration options in a template. For use with UFS1 or UFS2, set the sector_size to 2048: + [.programlisting] .... # $FreeBSD: src/sbin/gbde/template.txt,v 1.1.36.1 2009/08/03 08:13:06 kensmith Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] .... + man:gbde[8] will ask the user twice to type the passphrase used to secure the data. The passphrase must be the same both times. The ability of gbde to protect data depends entirely on the quality of the passphrase. For tips on how to select a secure passphrase that is easy to remember, see the http://world.std.com/~reinhold/diceware.html[Diceware Passphrase] website. + `gbde init` creates a lock file for the gbde partition. In this example, it is stored as [.filename]#/etc/gbde/ad4s1c.lock#. gbde lock files must end in ".lock" in order to be correctly detected by the [.filename]#/etc/rc.d/gbde# start up script. + [CAUTION] ==== gbde lock files _must_ be backed up together with the contents of any encrypted partitions. While deleting a lock file alone cannot prevent a determined attacker from decrypting a gbde partition, without the lock file, the legitimate owner will be unable to access the data on the encrypted partition without a significant amount of work that is totally unsupported by man:gbde[8]. ==== . Attach the Encrypted Partition to the Kernel + [source,shell] .... # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock .... + This command will prompt to input the passphrase that was selected during the initialization of the encrypted partition. The new encrypted device will appear in [.filename]#/dev# as [.filename]#/dev/device_name.bde#: + [source,shell] .... # ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde .... . Create a File System on the Encrypted Device + Once the encrypted device has been attached to the kernel, a file system can be created on the device using man:newfs[8]. This example creates a UFS2 file system with soft updates enabled. + [source,shell] .... # newfs -U /dev/ad4s1c.bde .... + [NOTE] ==== man:newfs[8] must be performed on an attached gbde partition which is identified by a [.filename]#*.bde# extension to the device name. ==== . Mount the Encrypted Partition + Create a mount point for the encrypted file system: + [source,shell] .... # mkdir /private .... + Mount the encrypted file system: + [source,shell] .... # mount /dev/ad4s1c.bde /private .... . Verify That the Encrypted File System is Available + The encrypted file system should now be visible to man:df[1] and be available for use. + [source,shell] .... % df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private .... ==== Mounting Existing Encrypted File Systems After each boot, any encrypted file systems must be re-attached to the kernel, checked for errors, and mounted, before the file systems can be used. The required commands must be executed as `root`. [.procedure] . Attach the `gbde` Partition to the Kernel + [source,shell] .... # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock .... + This command will prompt for the passphrase that was selected during initialization of the encrypted gbde partition. . Check the File System for Errors + Since encrypted file systems cannot yet be listed in [.filename]#/etc/fstab# for automatic mounting, the file systems must be checked for errors by running man:fsck[8] manually before mounting: + [source,shell] .... # fsck -p -t ffs /dev/ad4s1c.bde .... . Mount the Encrypted File System + [source,shell] .... # mount /dev/ad4s1c.bde /private .... + The encrypted file system is now available for use. ===== Automatically Mounting Encrypted Partitions It is possible to create a script to automatically attach, check, and mount an encrypted partition, but for security reasons the script should not contain the man:gbde[8] password. Instead, it is recommended that such scripts be run manually while providing the password via the console or man:ssh[1]. As an alternative, an [.filename]#rc.d# script is provided. Arguments for this script can be passed via man:rc.conf[5]: [.programlisting] .... gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" .... This requires that the gbde passphrase be entered at boot time. After typing the correct passphrase, the gbde encrypted partition will be mounted automatically. This can be useful when using gbde on laptops. ==== Cryptographic Protections Employed by `gbde` man:gbde[8] encrypts the sector payload using 128-bit AES in CBC mode. Each sector on the disk is encrypted with a different AES key. For more information on the cryptographic design, including how the sector keys are derived from the user-supplied passphrase, refer to man:gbde[4]. ==== Compatibility Issues man:sysinstall[8] is incompatible with gbde-encrypted devices. All [.filename]#*.bde# devices must be detached from the kernel before starting man:sysinstall[8] or it will crash during its initial probing for devices. To detach the encrypted device used in the example, use the following command: [source,shell] .... # gbde detach /dev/ad4s1c .... === Disk Encryption with `geli` An alternative cryptographic GEOM class is available through man:geli[8]. `geli` differs from `gbde`; offers different features, and uses a different scheme for doing cryptographic work. man:geli[8] provides the following features: * Utilizes the man:crypto[9] framework and, when cryptographic hardware is available, `geli` uses it automatically. * Supports multiple cryptographic algorithms such as AES, Blowfish, and 3DES. * Allows the root partition to be encrypted. The passphrase used to access the encrypted root partition will be requested during system boot. * Allows the use of two independent keys such as a "key" and a "company key". * `geli` is fast as it performs simple sector-to-sector encryption. * Allows backup and restore of master keys. If a user destroys their keys, it is still possible to get access to the data by restoring keys from the backup. * Allows a disk to attach with a random, one-time key which is useful for swap partitions and temporary file systems. More `geli` features can be found in man:geli[8]. This section describes how to enable support for `geli` in the FreeBSD kernel and explains how to create and use a `geli` encryption provider. Superuser privileges are required since modifications to the kernel are necessary. [.procedure] . Adding `geli` Support to the Kernel + For a custom kernel, ensure the kernel configuration file contains these lines: + [.programlisting] .... options GEOM_ELI device crypto .... + Alternatively, the `geli` module can be loaded at boot time by adding the following line to [.filename]#/boot/loader.conf#: + [.programlisting] .... geom_eli_load="YES" .... + man:geli[8] should now be supported by the kernel. . Generating the Master Key + The following example describes how to generate a key file which will be used as part of the master key for the encrypted provider mounted under [.filename]#/private#. The key file will provide some random data used to encrypt the master key. The master key will also be protected by a passphrase. The provider's sector size will be 4kB. The example will describe how to attach to the `geli` provider, create a file system on it, mount it, work with it, and finally, how to detach it. + It is recommended to use a bigger sector size, such as 4kB, for better performance. + The master key will be protected with a passphrase and the data source for the key file will be [.filename]#/dev/random#. The sector size of the provider [.filename]#/dev/da2.eli# will be 4kB. + [source,shell] .... # dd if=/dev/random of=/root/da2.key bs=64 count=1 # geli init -s 4096 -K /root/da2.key /dev/da2 Enter new passphrase: Reenter new passphrase: .... + It is not mandatory to use both a passphrase and a key file as either method of securing the master key can be used in isolation. + If the key file is given as "-", standard input will be used. This example shows how more than one key file can be used: + [source,shell] .... # cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2 .... . Attaching the Provider with the Generated Key + [source,shell] .... # geli attach -k /root/da2.key /dev/da2 Enter passphrase: .... + The new plaintext device will be named [.filename]#/dev/da2.eli#. + [source,shell] .... # ls /dev/da2* /dev/da2 /dev/da2.eli .... . Creating the New File System + [source,shell] .... # dd if=/dev/random of=/dev/da2.eli bs=1m # newfs /dev/da2.eli # mount /dev/da2.eli /private .... + The encrypted file system should now be visible to man:df[1] and be available for use: + [source,shell] .... # df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 248M 89M 139M 38% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr /dev/ad0s1d 989M 1.5M 909M 0% /tmp /dev/ad0s1e 3.9G 1.3G 2.3G 35% /var /dev/da2.eli 150G 4.1K 138G 0% /private .... . Unmounting and Detaching the Provider + Once the work on the encrypted partition is done, and the [.filename]#/private# partition is no longer needed, it is prudent to consider unmounting and detaching the `geli` encrypted partition from the kernel: + [source,shell] .... # umount /private # geli detach da2.eli .... More information about the use of man:geli[8] can be found in its manual page. ==== Using the [.filename]#geli# [.filename]#rc.d# Script `geli` comes with a [.filename]#rc.d# script which can be used to simplify the usage of `geli`. An example of configuring `geli` through man:rc.conf[5] follows: [.programlisting] .... geli_devices="da2" geli_da2_flags="-p -k /root/da2.key" .... This configures [.filename]#/dev/da2# as a `geli` provider of which the master key file is located in [.filename]#/root/da2.key#. `geli` will not use a passphrase when attaching to the provider if `-P` was given during the `geli init` phase. The system will detach the `geli` provider from the kernel before the system shuts down. More information about configuring [.filename]#rc.d# is provided in the crossref:config[configtuning-rcd,rc.d] section of the Handbook. [[swap-encrypting]] == Encrypting Swap Space Like the encryption of disk partitions, encryption of swap space is used to protect sensitive information. Consider an application that deals with passwords. As long as these passwords stay in physical memory, these passwords will not be written to disk and be cleared after a reboot. If FreeBSD starts swapping out memory pages to free space for other applications, the passwords may be written to the disk platters unencrypted. Encrypting swap space can be a solution for this scenario. The man:gbde[8] or man:geli[8] encryption systems may be used for swap encryption. Both systems use the [.filename]#encswap# crossref:config[configtuning-rcd,rc.d] script. [NOTE] ==== For the remainder of this section, [.filename]#ad0s1b# will be the swap partition. ==== Swap partitions are not encrypted by default and should be cleared of any sensitive data before continuing. To overwrite the current swap parition with random garbage, execute the following command: [source,shell] .... # dd if=/dev/random of=/dev/ad0s1b bs=1m .... === Swap Encryption with man:gbde[8] The `.bde` suffix should be added to the device in the respective [.filename]#/etc/fstab# swap line: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.bde none swap sw 0 0 .... === Swap Encryption with man:geli[8] The procedure for instead using man:geli[8] for swap encryption is similar to that of using man:gbde[8]. The `.eli` suffix should be added to the device in the respective [.filename]#/etc/fstab# swap line: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.eli none swap sw 0 0 .... man:geli[8] uses the AES algorithm with a key length of 128 bit by default. These defaults can be altered by using `geli_swap_flags` in [.filename]#/etc/rc.conf#. The following line tells the [.filename]#encswap# rc.d script to create man:geli[8] swap partitions using the Blowfish algorithm with a key length of 128 bits and a sectorsize of 4 kilobytes, and sets "detach on last close": [.programlisting] .... geli_swap_flags="-e blowfish -l 128 -s 4096 -d" .... Refer to the description of `onetime` in man:geli[8] for a list of possible options. === Encrypted Swap Verification Once the system has rebooted, proper operation of the encrypted swap can be verified using `swapinfo`. If man:gbde[8] is being used: [source,shell] .... % swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.bde 542720 0 542720 0% .... If man:geli[8] is being used: [source,shell] .... % swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.eli 542720 0 542720 0% .... [[disks-hast]] == Highly Available Storage (HAST) === Synopsis High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments. Highly Available STorage, or HAST, was developed by {pjd} as a framework which allows transparent storage of the same data across several physically separated machines connected by a TCP/IP network. HAST can be understood as a network-based RAID1 (mirror), and is similar to the DRBD(R) storage system known from the GNU/Linux(R) platform. In combination with other high-availability features of FreeBSD like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures. After reading this section, you will know: * What HAST is, how it works and which features it provides. * How to set up and use HAST on FreeBSD. * How to integrate CARP and man:devd[8] to build a robust storage system. Before reading this section, you should: * Understand UNIX(R) and crossref:basics[basics,FreeBSD Basics]. * Know how to crossref:config[config-tuning,configure] network interfaces and other core FreeBSD subsystems. * Have a good understanding of crossref:partiv[network-communication,FreeBSD networking]. The HAST project was sponsored by The FreeBSD Foundation with support from http://www.omc.net/[OMCnet Internet Service GmbH] and http://www.transip.nl/[TransIP BV]. === HAST Features The main features of the HAST system are: * Can be used to mask I/O errors on local hard drives. * File system agnostic as it works with any file system supported by FreeBSD. * Efficient and quick resynchronization, synchronizing only blocks that were modified during the downtime of a node. * Can be used in an already deployed environment to add additional redundancy. * Together with CARP, Heartbeat, or other tools, it can be used to build a robust and durable storage system. === HAST Operation As HAST provides a synchronous block-level replication of any storage media to several machines, it requires at least two physical machines: the `primary`, also known as the `master` node, and the `secondary` or `slave` node. These two machines together are referred to as a cluster. [NOTE] ==== HAST is currently limited to two cluster nodes in total. ==== Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time. The `primary` node, also called `active`, is the one which will handle all the I/O requests to HAST-managed devices. The `secondary` node is automatically synchronized from the `primary` node. The physical components of the HAST system are: * local disk on primary node, and * disk on remote, secondary node. HAST operates synchronously on a block level, making it transparent to file systems and applications. HAST provides regular GEOM providers in [.filename]#/dev/hast/# for use by other tools or applications, thus there is no difference between using HAST-provided devices and raw disks or partitions. Each write, delete, or flush operation is sent to the local disk and to the remote disk over TCP/IP. Each read operation is served from the local disk, unless the local disk is not up-to-date or an I/O error occurs. In such case, the read operation is sent to the secondary node. ==== Synchronization and Replication Modes HAST tries to provide fast failure recovery. For this reason, it is very important to reduce synchronization time after a node's outage. To provide fast synchronization, HAST manages an on-disk bitmap of dirty extents and only synchronizes those during a regular synchronization, with an exception of the initial sync. There are many ways to handle synchronization. HAST implements several replication modes to handle different synchronization methods: * _memsync_: report write operation as completed when the local write operation is finished and when the remote node acknowledges data arrival, but before actually storing the data. The data on the remote node will be stored directly after sending the acknowledgement. This mode is intended to reduce latency, but still provides very good reliability. * _fullsync_: report write operation as completed when local write completes and when remote write completes. This is the safest and the slowest replication mode. This mode is the default. * _async_: report write operation as completed when local write completes. This is the fastest and the most dangerous replication mode. It should be used when replicating to a distant node where latency is too high for other modes. === HAST Configuration HAST requires `GEOM_GATE` support which is not present in the default `GENERIC` kernel. However, the `geom_gate.ko` loadable module is available in the default FreeBSD installation. Alternatively, to build `GEOM_GATE` support into the kernel statically, add this line to the custom kernel configuration file: [.programlisting] .... options GEOM_GATE .... The HAST framework consists of several parts from the operating system's point of view: * the man:hastd[8] daemon responsible for data synchronization, * the man:hastctl[8] userland management utility, * and the man:hast.conf[5] configuration file. The following example describes how to configure two nodes in `master`-`slave` / `primary`-`secondary` operation using HAST to replicate the data between the two. The nodes will be called `hasta` with an IP address of _172.16.0.1_ and `hastb` with an IP of address _172.16.0.2_. Both nodes will have a dedicated hard drive [.filename]#/dev/ad6# of the same size for HAST operation. The HAST pool, sometimes also referred to as a resource or the GEOM provider in [.filename]#/dev/hast/#, will be called [.filename]#test#. Configuration of HAST is done using [.filename]#/etc/hast.conf#. This file should be the same on both nodes. The simplest configuration possible is: [.programlisting] .... resource test { on hasta { local /dev/ad6 remote 172.16.0.2 } on hastb { local /dev/ad6 remote 172.16.0.1 } } .... For more advanced configuration, refer to man:hast.conf[5]. [TIP] ==== It is also possible to use host names in the `remote` statements. In such a case, make sure that these hosts are resolvable and are defined in [.filename]#/etc/hosts# or in the local DNS. ==== Now that the configuration exists on both nodes, the HAST pool can be created. Run these commands on both nodes to place the initial metadata onto the local disk and to start man:hastd[8]: [source,shell] .... # hastctl create test # service hastd onestart .... [NOTE] ==== It is _not_ possible to use GEOM providers with an existing file system or to convert an existing storage to a HAST-managed pool. This procedure needs to store some metadata on the provider and there will not be enough required space available on an existing provider. ==== A HAST node's `primary` or `secondary` role is selected by an administrator, or software like Heartbeat, using man:hastctl[8]. On the primary node, `hasta`, issue this command: [source,shell] .... # hastctl role primary test .... Similarly, run this command on the secondary node, `hastb`: [source,shell] .... # hastctl role secondary test .... [CAUTION] ==== When the nodes are unable to communicate with each other, and both are configured as primary nodes, the condition is called `split-brain`. To troubleshoot this situation, follow the steps described in <>. ==== Verify the result by running man:hastctl[8] on each node: [source,shell] .... # hastctl status test .... The important text is the `status` line, which should say `complete` on each of the nodes. If it says `degraded`, something went wrong. At this point, the synchronization between the nodes has already started. The synchronization completes when `hastctl status` reports 0 bytes of `dirty` extents. The next step is to create a filesystem on the [.filename]#/dev/hast/test# GEOM provider and mount it. This must be done on the `primary` node, as [.filename]#/dev/hast/test# appears only on the `primary` node. Creating the filesystem can take a few minutes, depending on the size of the hard drive: [source,shell] .... # newfs -U /dev/hast/test # mkdir /hast/test # mount /dev/hast/test /hast/test .... Once the HAST framework is configured properly, the final step is to make sure that HAST is started automatically during system boot. Add this line to [.filename]#/etc/rc.conf#: [.programlisting] .... hastd_enable="YES" .... ==== Failover Configuration The goal of this example is to build a robust storage system which is resistant to the failure of any given node. The scenario is that a `primary` node of the cluster fails. If this happens, the `secondary` node is there to take over seamlessly, check and mount the file system, and continue to work without missing a single bit of data. To accomplish this task, another FreeBSD feature, CARP, provides for automatic failover on the IP layer. CARP (Common Address Redundancy Protocol) allows multiple hosts on the same network segment to share an IP address. Set up CARP on both nodes of the cluster according to the documentation available in crossref:advanced-networking[carp,Common Access Redundancy Protocol (CARP)]. After setup, each node will have its own [.filename]#carp0# interface with a shared IP address of _172.16.0.254_. The primary HAST node of the cluster must be the master CARP node. The HAST pool created in the previous section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through NFS or Samba, using the shared IP address _172.16.0.254_. The only problem which remains unresolved is an automatic failover should the primary node fail. In the event of CARP interfaces going up or down, the FreeBSD operating system generates a man:devd[8] event, making it possible to watch for state changes on the CARP interfaces. A state change on the CARP interface is an indication that one of the nodes failed or came back online. These state change events make it possible to run a script which will automatically handle the HAST failover. To be able to catch state changes on the CARP interfaces, add this configuration to [.filename]#/etc/devd.conf# on each node: [.programlisting] .... notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; action "/usr/local/sbin/carp-hast-switch master"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; action "/usr/local/sbin/carp-hast-switch slave"; }; .... Restart man:devd[8] on both nodes to put the new configuration into effect: [source,shell] .... # service devd restart .... When the [.filename]#carp0# interface state changes by going up or down , the system generates a notification, allowing the man:devd[8] subsystem to run an arbitrary script, in this case [.filename]#/usr/local/sbin/carp-hast-switch#. This script handles the automatic failover. For further clarification about the above man:devd[8] configuration, refer to man:devd.conf[5]. An example of such a script could be: [.programlisting] .... #!/bin/sh # Original script by Freddie Cash # Modified by Michael W. Lucas # and Viktor Petersson # The names of the HAST resources, as listed in /etc/hast.conf resources="test" # delay in mounting HAST resource after becoming master # make your best guess delay=3 # logging log="local0.debug" name="carp-hast" # end of user configurable stuff case "$1" in master) logger -p $log -t $name "Switching to primary provider for ${resources}." sleep ${delay} # Wait for any "hastd secondary" processes to stop for disk in ${resources}; do while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do sleep 1 done # Switch role for each disk hastctl role primary ${disk} if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to change role to primary for resource ${disk}." exit 1 fi done # Wait for the /dev/hast/* devices to appear for disk in ${resources}; do for I in $( jot 60 ); do [ -c "/dev/hast/${disk}" ] && break sleep 0.5 done if [ ! -c "/dev/hast/${disk}" ]; then logger -p $log -t $name "GEOM provider /dev/hast/${disk} did not appear." exit 1 fi done logger -p $log -t $name "Role for HAST resources ${resources} switched to primary." logger -p $log -t $name "Mounting disks." for disk in ${resources}; do mkdir -p /hast/${disk} fsck -p -y -t ufs /dev/hast/${disk} mount /dev/hast/${disk} /hast/${disk} done ;; slave) logger -p $log -t $name "Switching to secondary provider for ${resources}." # Switch roles for the HAST resources for disk in ${resources}; do if ! mount | grep -q "^/dev/hast/${disk} on " then else umount -f /hast/${disk} fi sleep $delay hastctl role secondary ${disk} 2>&1 if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to switch role to secondary for resource ${disk}." exit 1 fi logger -p $log -t $name "Role switched to secondary for resource ${disk}." done ;; esac .... In a nutshell, the script takes these actions when a node becomes `master` / `primary`: * Promotes the HAST pools to primary on a given node. * Checks the file system under the HAST pool. * Mounts the pools at an appropriate place. When a node becomes `backup` / `secondary`: * Unmounts the HAST pools. * Degrades the HAST pools to secondary. [CAUTION] ==== Keep in mind that this is just an example script which serves as a proof of concept. It does not handle all the possible scenarios and can be extended or altered in any way, for example, to start/stop required services. ==== [TIP] ==== For this example, a standard UFS file system was used. To reduce the time needed for recovery, a journal-enabled UFS or ZFS file system can be used instead. ==== More detailed information with additional examples can be found in the http://wiki.FreeBSD.org/HAST[HAST Wiki] page. === Troubleshooting ==== General Troubleshooting Tips HAST should generally work without issues. However, as with any other software product, there may be times when it does not work as supposed. The sources of the problems may be different, but the rule of thumb is to ensure that the time is synchronized between all nodes of the cluster. When troubleshooting HAST problems, the debugging level of man:hastd[8] should be increased by starting man:hastd[8] with `-d`. This argument may be specified multiple times to further increase the debugging level. A lot of useful information may be obtained this way. Consider also using `-F`, which starts man:hastd[8] in the foreground. [[disks-hast-sb]] ==== Recovering from the Split-brain Condition `Split-brain` is when the nodes of the cluster are unable to communicate with each other, and both are configured as primary. This is a dangerous condition because it allows both nodes to make incompatible changes to the data. This problem must be corrected manually by the system administrator. The administrator must decide which node has more important changes (or merge them manually) and let HAST perform full synchronization of the node which has the broken data. To do this, issue these commands on the node which needs to be resynchronized: [source,shell] .... # hastctl role init # hastctl create # hastctl role secondary ....