Network RAID

If you have multiple computers that already run 24/7 on your own network, and if they happen to have unused capacity, you might want to serve up these resources to other PCs. If you take this idea a step farther, you end up with something like a RAID system whose storage you can quickly provide from a central location. Because multiple computers are involved, there are some trade-offs in terms of probability of failure, but the choice of an appropriate RAID level takes the bite out of this potential explosiveness.

The following example creates a RAID 5 array for simplicity's sake. In the first step, the admin creates a raw image on each of three systems (Figures 1 and 2). The RAID array is easily generated with the mdadm command (Listing 1). On the newly created RAID array, you can then create, for example, an ext4 filesystem:

mkfs.ext4 -L nwraid /dev/md0

# mdadm --create /dev/md0 --auto md --level=5 --raid-devices=3 /dev/etherd/e1.1 /dev/etherd/e2.1 /dev/etherd/e3.1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

To revive the RAID array on another system, in case of initiator failure, without any great loss of time, you will want to create a matching mdadm configuration file (mdadm.conf) and store it in a safe place (Listing 2).

If you are game for an adventure, you can use Btrfs instead of mdadm; after all, it is much simpler to handle than mdadm, and it offers more options – such as inline compression or snapshots. Listing 3 shows how easy it is to set up a RAID array with Btrfs.

# mkfs.btrfs -d raid5 -m raid5 -L nwraid /dev/etherd/e1.1 /dev/etherd/e2.1 /dev/etherd/e3.1
WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
adding device /dev/etherd/e2.1 id 2
adding device /dev/etherd/e3.1 id 3
Setting RAID5/6 feature flag
fs created label nwraid on /dev/etherd/e1.1
        nodesize 4096 leafsize 4096 sectorsize 4096 size 29.30GB
Btrfs v0.20-rc1

Backup and Virtualization

If you frequently need to create disk backups over the network (as is often the case, e.g., in data forensics), you will really enjoy working with AoE: Providing a data carrier over the network is a much faster process compared with iSCSI.

AoE also is much more convenient compared with a backup using Netcat in conjunction with dd or ewfacquire, and forensic scientists will love the fact that the popular backup program Guymager [2] instantly identifies AoE devices (Figure 3).

Figure 3: The forensic tool Guymager recognizes AoE drives at once and supports fast saving of whole data storage devices over the network.

The joy is clouded a little in that vblade is currently only included with Debian, on the Grml Live CD [3], and in Caine [4] version 5. Users with other distributions need to turn to SourceForge [5]. In response to my inquiries to the major projects, only DEFT Linux [6] responded with a promise to add vblade in the next release.

Virtualizing Seized Systems

AoE is a useful tool for virtualization purposes. In conjunction with xmount [7], admins can quickly serve up a secure image as a virtual disk (Listing 4). Forensic scientists who want to deploy a disk image in Encase format with write support should first convert it to a raw image and then embed the raw file as a data carrier.

# xmount --in ewf --out dd --cache file.ovl diskimage.e?? /mnt/analysis
# vblade 2 3 eth0 /mnt/analysis/diskimage.dd

On a remote computer, the system can be virtualized with qemu-kvm, for example. In the simplest possible case, you would enter

qemu-kvm -m 1024 -hda /dev/etherd/e2.3

to do deliberately without possible optimizations and not make any changes to the host system for the new environment but output much clearer error messages.