An encrypted backup of a disk/partition to a Samba share with Clonezilla
You will learn how to customize Clonezilla Live (v. 1.2.5-24) for an easy backup of a partition (or a disk) to an encrypted file stored on a remote Samba server and how to test the backup by restoring it to a VMware virtual machine. We will few scripts to simplify the task, including a custom Clonezilla startup script to mount a TrueCrypt volume on a Samba share.
Content: What is Clonezilla? | Preparing Clonezilla for a custom backup | Backup | Encryption of the backup | Restoration and testing of the backup | The complete backup - encrypt - test cycle | Summary
PS: If you are scared by the length of this post then read only "The complete backup – encrypt – test cycle" :-)
Update 2010-09-23: Added "The complete backup – encrypt – test cycle", little reorganization.
The normal mode of operation of Clonezilla is:
For setup and testing it's comfortable to be able to run Clonezilla in a VMware. My blog Booting from a USB stick in VMware Player explains how to run an operating system installed on a USB flash disk in VMware, which doesn't support that out of the box.
The customizations:
Notice that by default Clonezilla splits the backup files into 2GB pieces, which is very useful because we will store them to a TrueCrypt volume with the FAT file system, which can't handle larger files.
Therefore I use the boot configuration "JH Clonezilla offline (Safe graphic)" to back-up to a local external disk and the boot config. "JH Clonezilla for Samba (Safe graphic)" to either back-up to Samba or to restore the encrypted remote backup.
Personally I'd prefer eCryptfs because it encrypts each file individually and you don't need to create a container of a fixed size but it only works under Linux and is more difficult to install (you need to include a support in the kernel etc.) and when I tried it the backup to an eCryptfs folder failed with the error "NT_STATUS_ACCESS_DENIED -> CIFS VFS send error in read = -13". I guess there is some issue between eCryptfs and Samba. Therefore I've chosen TrueCrypt, which worked well.
Advantages of truecrypt: mature and stable, cross-platform, all that is needed is a single binary.
Disadvantages: The size of the container must be specified in advance and be large enough to hold all the content, manipulation with such a large file is difficult. Under Linux it has only a command-line interface.
Working with TrueCrypt:
Resources: The discussion Restore partition to new harddrive, another related forum question, and a description of the cnvt-ocs-dev utility.
Few notes
To restore the uncompressed image with partclone:
0. Preparation
The script live/truecrypt/tc-create-volume-on-samba.sh:
Content: What is Clonezilla? | Preparing Clonezilla for a custom backup | Backup | Encryption of the backup | Restoration and testing of the backup | The complete backup - encrypt - test cycle | Summary
PS: If you are scared by the length of this post then read only "The complete backup – encrypt – test cycle" :-)
Update 2010-09-23: Added "The complete backup – encrypt – test cycle", little reorganization.
What is Clonezilla?
Clonezilla is a live Linux distribution containing tools for performing backup and restoration of disks and partitions. It is basically a collection of various open-source tools such as partimage and gzip and custom scripts that "glue" them together to create a single backup tool driven by a wizard-like user interface. You install it to a CD or USB flash disk, boot from that medium, answer few questions and a backup or a restoration may start.The normal mode of operation of Clonezilla is:
- You boot from the Clonezilla live CD or USB (screenshot)
- (Network connection may be or may be not set up based on the kernel boot parameters.)
- The Clonezilla script specified in the kernel boot parameters (default: ocs-live-general) is executed; it does a few things:
- It asks what to do (screenshot): start Clonezilla (the wizard) or enter command line; choose to start Clonezilla
- Use an image file or a physical partition (screenshot) as the target/source of the backup/restore?
- Next you are asked where to store the backup (screenshot). The target device must be mounted as /home/partimag/. You can select a local disk (such as a portable external disk connected via USB) or select to enter the command line to mount something (e.g. a remote Samba folder) manually.
- You are asked about what to do (screenshot): backup a disk, backup selected partition(s), restore a disk, restore partition(s), etc.
- You can select either Beginner or Advanced mode; the latter let you choose the compression algorithm and modify other options.
- Next, when doing a backup, you must choose the disk or partition to back up.
- Finally you can choose what to do when the operation is finished, such as turning the computer off, rebooting or nothing.
- After few confirmations the backup starts. The Clonezilla command created based on your choices is shown and also stored to a temporary file - you may want to run it directly from the command line the next time without going through the wizard (though you will still need to mount the target device).
- Before, during, or after the backup you can enter the command line to do anything you need.
Selected features
- Backup the whole disk or only a selected partition(s)
- Compression of the backup
- Works on the raw disk level, i.e. below the filesystem level
- Only backs up the used blocks on the source disk/partition, unused space of the disk doesn't add to the backup size
- Incremental backup is not supported
Limitations
- Cannot restore to a disk smaller than the backed-up disk even if the data on the original disk are smaller than the target disk (Actually a limitation of partimag.)
- Doesn't support encryption - but that can be added externally, see below
- Cannot restore to a partition of a different number (sda1 x sda2) or on a different disk (sda1 x sdb1) - but we will learn how to work around that
Preparing Clonezilla for a custom backup
First of all, download the USB flash disk version of Clonezilla Live (easier to customize), i.e. the .zip version (mine was clonezilla-live-1.2.5-24-i686.zip, with clonezilla 2.3.something installed) and unpack it to a USB flash disk (USB stick).For setup and testing it's comfortable to be able to run Clonezilla in a VMware. My blog Booting from a USB stick in VMware Player explains how to run an operating system installed on a USB flash disk in VMware, which doesn't support that out of the box.
The customizations:
- Adding custom files: Most files in the Clonezilla distribution are read-only and any changes to them are ignored. There is a single folder where changes are persistent: <USB stick with Clonezilla>/live/, which is accessible as /live/image/live/ from within Clonezilla Live when it's running.
- Add here the necessary files: truecrypt (see Encryption of the backup - TrueCrypt below), scripts jh-my-mounts, jh-ocs-live-general (shown below)
- Customizing Clonezilla boot menu in /syslinux/syslinux.cfg (shown below): We will add our own entries to the boot menu with customized kernel startup parameters to set our prefered default values for some options not to be asked for them each time, to tune the environment (switch numlock on etc.), and to tell Clonezilla what script it should run instead of its default one. Points of interest:
- Common customized boot parameters:
ocs_numlk=on- enable Num Lock upon startupocs_live_keymap="NONE" ocs_lang="en_US.UTF-8"- provide values for these options so that Clonezilla doesn't ask for themvga=normal- on one PC I had some problems with the graphics in Clonezilla (likely something between framebuffer and NVidia), this setting resolved that
- The boot configuration "JH Clonezilla for Samba (Safe graphic)"
- Networking is enabled (the default), Clonezilla will try to connect using DHCP
ocs_live_run="/live/image/live/jh-ocs-live-general"- this script will be run upon startup instead of the default ocs-live-general; the main change being that when you select Start Clonezilla then it will mount the preconfigured Samba share as /mnt/backupbytovka/ and the latest TrueCrypt volume on it (if any) as /home/partimag using the functions from jh-my_mounts.sh
- The boot configuration "JH Clonezilla offline (Safe graphic)"
ip=frommedia- disables network
- Important: don't forget to comment out MENU DEFAULT for the original Clonezilla entry by inserting # in front of it
- Common customized boot parameters:
Custom(ized) files
Customized syslinux/syslinux.cfg:
- Only the added/modified part displayed
- We add two entries and comment out an existing entry's line "MENU DEFAULT" by prepending it with #
...
label Clonezilla live without framebuffer
MENU DEFAULT
MENU LABEL JH Clonezilla for Samba (Safe graphic)
kernel /live/vmlinuz
append initrd=/live/initrd.img boot=live ocs_numlk=on noswap nolocales edd=on noprompt ocs_live_run="/live/image/live/jh-ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="NONE" ocs_live_batch="no" ocs_lang="en_US.UTF-8" vga=normal nomodeset nosplash
TEXT HELP
Disable console frame buffer support
ENDTEXT
label Clonezilla live without framebuffer
MENU DEFAULT
MENU LABEL JH Clonezilla offline (Safe graphic)
kernel /live/vmlinuz
append initrd=/live/initrd.img boot=live ip=frommedia ocs_numlk=on noswap nolocales edd=on noprompt ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="NONE" ocs_live_batch="no" ocs_lang="en_US.UTF-8" vga=normal nomodeset nosplash
TEXT HELP
Disable console frame buffer support
ENDTEXT
# Since no network setting in the squashfs image, therefore if ip=frommedia, the network is disabled. That's what we want.
label Clonezilla live
# MENU DEFAULT
# MENU HIDE
...
Custom Clonezilla script live/jh-ocs-live-general:
This script is run by Clonezilla when it boots and displays a menu-driven wizard. The modified parts are marked with ### JHn BEGIN ... ### JHn END. The important changes are:- A script with helper functions is sourced
- When Start Clonezilla is invoked, the hardwired Samba share is mounted
- Then the latest TrueCrypt volume on the Samba share is mounted to /home/partimag
- When Clonezilla finishes the TrueCrypt volume and Samba share will be unmounted.
#!/bin/bash
# Author: Steven Shiau
# License: GPL
# Description: Program to start saving or restoring image in Clonezilla live.
# Load DRBL setting and functions
DRBL_SCRIPT_PATH="${DRBL_SCRIPT_PATH:-/opt/drbl/}"
. $DRBL_SCRIPT_PATH/sbin/drbl-conf-functions
. $DRBL_SCRIPT_PATH/conf/drbl-ocs.conf
. $DRBL_SCRIPT_PATH/sbin/ocs-functions
# load the setting for clonezilla live.
[ -e /etc/ocs/ocs-live.conf ] && . /etc/ocs/ocs-live.conf
# Get the live media mount point.
get_live_media_mnt_point
# prepare the clonezilla live environment.
ocs-live-env-prepare
### JH1 BEGIN - mount my mounts [displays after the start clonezilla/enter shell dialog]
. /live/image/live/jh-my_mounts.sh
echo ">>>JH: Mounting Samba..."
# mount_remote_samba2backupbytovka
mount_remote_samba2backupbytovka
echo ">>>JH: Going to mount TrueCrypt, provide its password when asked..."
mount_truecrypt
### JH1 END
# Do not ask powerer/reboot/choose (-p) in ocs-sr, just use "-p true". Since it might be in bterm, and Debian live "Press Enter" message when poweroff/shutdown might be coverd by bterm and user will not have any idea what's happening after choose poweroff/reboot.
# ocs_lang and ocs_live_extra_param are loaded from /etc/ocs/ocs-live.conf
# "-n" was added since we will run show-general-ocs-live-prompt after command clonezilla
clonezilla -l $ocs_lang -p true -n $ocs_live_extra_param
### JH2 BEGIN - umount my mounts...
echo ">>>JH: Umounting Truecrypt and Samba drives..."
umount_all
### JH2 END
# Show prompt
show-general-ocs-live-prompt
Helper mount script live/jh-my_mounts.sh:
Noteworthy: we use whiptail to show a dialog that asks the user for his/her TrueCrypt volume password.
#!/bin/bash
##
## MOUNT THE ENCRYPTED SAMBA FOLDER FOR STORING BACKUPS
##
## Run as root. You may want to add it to the boot parameters as:
## ocs_prerun="/live/image/live/mount_backupbytovka.sh"
# 1. Mount the hardwired Samba share to the given mount point [default: /mnt/backupbytovka]
mount_remote_samba2backupbytovka() {
if [ ! -z "$1" ]; then mpoint="$1"; else mpoint=/mnt/backupbytovka; fi
if [ ! -e "$mpoint" ]; then sudo mkdir "$mpoint" || die "Failed to create the mountpoint '$mpoint'"; fi
sudo mount -t cifs -o username="bob",password="secret" "//172.24.4.77/bob" $mpoint || die "samba mount failed for mount point '$mpoint'"
}
mnt_samba() {
mount_remote_samba2backupbytovka "$@"
}
# 2. Mount TrueCrypt the most recent TC volume in /mnt/backupbytovka to the given mount point [default: /home/partimag]
mount_truecrypt() {
# IN PARAMS
if [ ! -z "$1" ]; then mpoint="$1"; else mpoint=/home/partimag; fi
if [ ! -e "$mpoint" ]; then die "The mountpoint '$mpoint' doesn't exist!"; fi
if [ ! -z "$2" ]; then tcVolumeFolder="$2"; else tcVolumeFolder=/mnt/backupbytovka; fi
if [ ! -d "$tcVolumeFolder" ]; then die "The folder '$tcVolumeFolder', expected to containt the TrueCrypt volume, doesn't exist!"; fi
tcVolume=$(ls -1 -t "$tcVolumeFolder"/*.tc | head -n1)
if [ ! -f "$tcVolume" ]; then die "The Truecrypt volume '$tcVolume' (I looked for *.tc in $tcVolumeFolder) doesn't exist."; fi
echo ">>>JH: Going to mount Truecrypt, provide its password when asked..."
truecryptPsw=$(whiptail --passwordbox "Truecrypt Password" 10 30 3>&1 1>&2 2>&3)
# Mount a volume prompting for nothing (no password, keyfile, whether to protect a hidden part.):
# (Notice that specifying the psw on the command line isn't secure as it can be seen e.g. in the output of ps)
/live/image/live/truecrypt/truecrypt -t -k "" --protect-hidden=no --password="$truecryptPsw" "$tcVolume" "$mpoint"
}
umount_truecrypt() {
# Dismount all mounted TC volumes:
/live/image/live/truecrypt/truecrypt -t -d
}
die() {
echo "FATAL FAILURE: $1"
exit 1
}
# 3. END
umount_all() {
umount_truecrypt || echo "WARN: Truecrypt umount failed (/home/partimag)"
sudo umount /mnt/backupbytovka || echo "WARN: Samba umount failed (/mnt/backupbytovka)"
}
About Clonezilla file system customization
As mentioned, with the exception of the folder live/, the Clonezilla filesystem is read-only. During boot it is extracted from live/filesystem.squashfs. It is possible to modify this Squash file system used by Clonezilla but I found it rather cumbersome and difficult and therefore recommend to avoid it. (You need to install some tools with the correct versions, "unsquash" the filesystem, modify it, "squash" it again, and use the outcome file to replace the original one.)Backup
Restart your PC, boot from the USB flash disk with Clonezilla Live and start the Clonezilla program - or your customized script - to perform the backup.Notice that by default Clonezilla splits the backup files into 2GB pieces, which is very useful because we will store them to a TrueCrypt volume with the FAT file system, which can't handle larger files.
Back up to a TrueCrypt volume on a Samba share or to an external disk?
If your space is limited you may want to do the backup in one step by storing it directly into a (new or existing) TrueCrypt volume on a Samba share. However I prefer first to create an unencrypted backup on an external disk connected directly to the computer and only then create a TrueCrypt volume on the share and move the backup there. That way the several hours long backup can't be interrupted by a network/Samba/TrueCrypt failure and also I know exactly how large TC volume I need to create to hold the backup.Therefore I use the boot configuration "JH Clonezilla offline (Safe graphic)" to back-up to a local external disk and the boot config. "JH Clonezilla for Samba (Safe graphic)" to either back-up to Samba or to restore the encrypted remote backup.
Compression - observations
Clonezilla offers several compression algorithms differing in speed and compression ratio in the advanced mode. I've tried three of them:- gzip: ~ 350MB/min, compressed to ~ 70% (ex.: 108 to 77GB, done in ~ 3hrs)
- lzo: ~ 650MB/m, compressed to 86%
- lzma? ~ the slowest compression is indeed slower by one order (few tens of MB/m)
Encryption of the backup
Clonezilla doesn't support encryption of the backup but you can use an external solution such as an encrypted volume or filesystem. I've considered eCryptfs, which I normally use under Linux, and TrueCrypt.Personally I'd prefer eCryptfs because it encrypts each file individually and you don't need to create a container of a fixed size but it only works under Linux and is more difficult to install (you need to include a support in the kernel etc.) and when I tried it the backup to an eCryptfs folder failed with the error "NT_STATUS_ACCESS_DENIED -> CIFS VFS send error in read = -13". I guess there is some issue between eCryptfs and Samba. Therefore I've chosen TrueCrypt, which worked well.
TrueCrypt
Truecrypt makes it possible to create an encrypted "container", i.e. an encrypted file that can contain a filesystem and be mounted as a physical volume.Advantages of truecrypt: mature and stable, cross-platform, all that is needed is a single binary.
Disadvantages: The size of the container must be specified in advance and be large enough to hold all the content, manipulation with such a large file is difficult. Under Linux it has only a command-line interface.
Working with TrueCrypt:
- Download Truecrypt 6.3a, the console-only version
- Run the extracted file and select not to install but to extract .tar.gz; unpack it and move the bin/truecrypt to /live/truecrypt/truecrypt
- Create an encrypted container on the Samba share either using the wizard (truecrypt -c mycontainer.tc) or by specifying all options on the command line
- During the process, select the defaults (AES, RIPEMD-160, fs FAT), enter 320 random characters
- Specifying all the options on the command line (in bash use $[77*1024**3] to convert 77GB to bytes):
truecrypt-console-6.3a --volume-type=normal --size=[size in bytes] --encryption=AES --hash=RIPEMD-160 --filesystem=FAT -k "" -c truecryptvol.empty.tc - Creating a container of the size 110GB will take a couple of hours based on the network/HDD speed (4h with 6.8MB/s) - TC must create and write random data all over the disk
- Note: According to one source, SHA-1 is slightly faster than RIPEMD (~ by 1/6 under ideal conditions
- Note: You can of course choose other than the default options but I prefered to stick with them so that I don't need to remember what options I've chosen
- Mount the volume: truecrypt truecryptvol.tc /home/partimag
- You'll be asked first for the truecrypt container password ("Enter password for truecryptvol.tc:") and then for your user or administrator password ("Enter your user password or administrator password:"), unless running as root, because it's required to use/mount the loop device or so something.
- Unmount all truecrypt volumes: truecrypt -d
TrueCrypt Linux command-line options
The official documentation only describes rather limited Windows command-line options. Execute truecrypt -h to learn about the options available under Linux (or see TrueCrypt's Main/CommandLineInterface.cpp).Restoration and testing of the backup
How to restore to a different disk and/or partition
Normally you can only restore to the same disk or partition. To go around this limitation you need to modify the backup files:- To restore to a different disk, use (from within Clonezilla) the command cnvt-ocs-dev to rename the backup files (you could also do it manually but this is a supported way). Example:
cnvt-ocs-dev 2010-06-15-16-img sda sdb - To restore to a different partition you must change the partition number(s) manually by renaming for instance sda1.* to sda2.*:
for BKP in $(ls sda1.*); do BKPNEW=$(echo $BKP | sed "s/sda1/sda2/"); mv $BKP $BKPNEW; done
Failed to restore partition image file /home/partimag/2010-06-15-16-img/sda1/* to /dev/sda1! Maybe this image is corrupt!Resources: The discussion Restore partition to new harddrive, another related forum question, and a description of the cnvt-ocs-dev utility.
Manual restore of the backup
There are several cases when you may prefer to have full control over the restoration process, for example if Clonezilla's kernel causes the source/target USB disk to get disconnected before it finishes ("usb 1-1: reset high speed USB device using ehci_hcd and address 2"). The process is well described in the Clonezilla FAQ How to restore backup manually into a mountable .img file (if partclone was used for the backup; it's similar for ntfsclone and thate are also partclone-utils that can read the image directly though you'll likely need to uncompress it anyway ) - you need to join all the parts (.aa, .ab etc.) via cat and pass them to the proper un-archiver and either store the complete uncompressed image or pass it directly tto the cloning tool for restoration.Decompression
You need to join the backup parts (.aa, .ab, up to perhaps, .zz) and uncompress them. You can recognize the compression algorithm from the backup part name, for example sda1.ext4-ptcl-img.lzo.aa was copressed wih lzo, or by running the command file on the first part: file sda1.ext4-ptcl-img.lzo.aa => "sda1.ext4-ptcl-img.lzo.aa: lzop compressed data - version 1.020, LZO1X-1, os: Unix".cat sda1.ext4-ptcl-img.lzo.* | lzop -d -vvv > sda1.ext4-ptcl-imgFew notes
- I had to rename *.aa to *.a1 - for some reason bash didn't list is as the first file.
- To me it took ~ 13h to decompress an lzo-compressed image of the output size 197GB on 2-core Intel Atom 230 (1.6GHz) PC while reading from&writting to an external 5400 RPM disk
Restoration
You can recognize the tool used to create the image from its name, for example the name contains "ptcl" then Partclone was used to create it.To restore the uncompressed image with partclone:
sudo partclone.restore --restore_row_file -C -s sda1.ext4-ptcl-img -o sda1.ext4-ptcl-restored2.img- To me it took > 14h to restore my image of a device with the size 282GB (70GB of that free) on 2-core Intel Atom 230 (1.6GHz) PC while reading from&writting to an external 5400 RPM disk
- The flag --restore_row_file, available since Partclone 0.2.16, is essential if you want to mount the image and avoid the following:
shell$ mount -t ext4 -o loop,nosuid,nodev /media/mydisk/sda1.ext4-ptcl-restored.img /mnt mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error ... shell$ dmesg | tail EXT4-fs (loop0): bad geometry: block count 16544941 exceeds size of device (16257568 blocks)
Many thanks to senden9 (Stefano Probst?) for finding this solution!!!
Access
To access the content of the restored image:sudo mount -t ext4 -o loop,nosuid,nodev /media/mydisk/sda1.ext4-ptcl-restored.img /mntBooting from the restored image with VMWare
TBDTesting by restoring to VMWare
To test the backup, we will restore it to a virtual harddisk of a VMware virtual machine. It will be simpler if the disk name (such as sda or sdb) and the partition numbers match those of the backup. If not, you will need to modify the backup to match the name and number(s) as described above.0. Preparation
- Add a virtual disk to a new or an existing VMware machine; it must be at least as large as the backed-up partition. I think it is unnecessary to allocate all the space immediately because the main bottleneck of the restoration will be the network and not the dynamic expansion of the harddisk file. Also, it may take few hours to create.
- Run the vmware machine with that disk, booting from the USB stick with Clonezilla Live (see how to boot from an USB in VMware)
- In the Clonezilla boot menu, choose the option that starts networking (JH Clonezilla for Samba)
- Mount the volume holding the backup as /home/partimag; for a TrueCrypt volume on a Samba share:
- Start Clonezilla, select the device-image mode, on the screen "Mount Clonezilla image directory" select "enter_shell"
- Thanks to the customized Clonezilla script, the Samba share should be mounted as /mnt/backupbytovka when you select to Start Clonezilla. You can also do it manually:
cd /live/image/live; . jh-my_mounts.sh; mnt_samba - Mount the most recent TrueCrypt volume on the share to /home/partimag:
cd /live/image/live; . jh-my_mounts.sh; mount_truecrypt
(you will be asked for a TC password) - Verify the backup: ls /home/partimag/ => should contain files like sda2.ext3-ptcl-img.gz.aa, .ab etc.
- Execute 'exit' twice to get back to the Clonezilla dialog
- Use fdisk to create a partition on the new large virtual disk for the backup restoration (you may want to do this and make a copy of the disk for future tests)
- You may want to create some small partitions first so that the actual target partition has the same number as the backed-up partition to avoid the need to adjust the backup
- To find the right disk, as root: # lsscsi - look for lines like "[...] disk VMWare, VMware Virtual S 1.0 /dev/sda"; use fdisk -l to find out the disk size, which should be enough to recognize the right one
- Execute e.g. fdisk /dev/sdb and then
- Execute the commands 'c', 'u' as suggested by fdisk
- Create a partition with 'n' (select p as primary, the part. nr. 1, size as desired, ...) ...
- Make the partition bootable with 'a'
- Finally store the configuration with 'w'
- If the disk name differs from the backup source disk, modify the backup using cnvt-ocs-dev as described above
- Use clonezilla to restore to the disk (Example duration - estim. time > 6h with 290MB/min, i.e. <5MB/s)
- Restart VMware and when booting press Esc to display the Boot menu (you may want to increase the boot screen delay to have enough time for that). You should be able to select a boot disk here but I wasn't able to expand the Hard Drive section => select <Enter Setup> and on the Boot tab move the Hard Drive with the restored backup to the first place, F10 to save and boot from it.
The complete backup - encrypt - test cycle
To sum it up, this is how I proceed with my backups:1. Backup to a localy mounted flash disk
- Boot Clonezilla in the mode "JH Clonezilla offline (Safe graphic)"
- Backup a partition (sda2) to a localy mounted flash disk:
- Run the Clonezilla user interface (UI) and instruct it to mount the flash disk as the image storage
- Either continue with the UI or quit it and run manually the command saved from the previous run, in my case (slightly improved):
/opt/drbl/sbin/ocs-sr -q2 -c -j2 -z1 -i 2000 -p true saveparts $(date "+%Y-%m-%d-%H")-img sda2
2. Move the backup image to a new remote TrueCrypt volume
- Boot your computer normally and run a terminal (of course you could do it from Clonezilla Live too)
- Start bash inside bash for further operations (the functions call exit upon failure and would thus close the terminal window)
- Mount the remote Samba folder:
$ source <Clonezilla USB>/live/jh-my_mounts.sh; mnt_samba - Create a TrueCrypt volume on it (for me this takes couple of hours, such as 5-6h for 90GB):
$ <Clonezilla USB>live/truecrypt/tc-create-volume-on-samba.sh <size in GB or path to the Clonezilla image folder> - Mount the TC volume:
$ mkdir /tmp/tcmount; mount_truecrypt /tmp/tcmount - Move the backup image folder into the volume:
$ mv <Clonezilla image folder> /tmp/tcmount/ - Umount TrueCrypt and Samba:
$ umount_all
The script live/truecrypt/tc-create-volume-on-samba.sh:
#!/bin/bash
## Create a new TrueCrypt volume on an already mounted Samba share
## with size either given or determined from the size of a folder given
die() {
echo "FATAL FAILURE: $1"
exit 1
}
## CHECK INPUTS
if [ $# -ne 1 ]; then
die "Usage: $0 <size in GB or a path to a Clonezilla image folder>"
fi
SIZE_PARAM="$1"
if [ "$(echo '$SIZE_PARAM' | grep "^[ [:digit:] ]*$")" ]
then
SIZE_GB=$SIZE_PARAM
echo "Volume size source: size in GB specified directly"
else
if [ -d "$SIZE_PARAM" ]
then
SIZE_GB=$(du -s -B 1G "$SIZE_PARAM" | cut -f1)
echo "Volume size source: computed from the size of the given folder"
else die "Parameter 1 must be either the desired volume size in GB (an integer) or a folder whose size will be used to determine the volume size; was: '$SIZE_PARAM'"
fi
fi
SIZE_BYTES=$[$SIZE_GB*1024**3]
echo "Volume size will be $SIZE_GB GB = $SIZE_BYTES B; based on $SIZE_PARAM"
## CHECK ENVIRONMENT
MPOINT=/mnt/backupbytovka
if [ ! "$(mount | grep $MPOINT)" ]; then die "The place where to create the volume, '$MPOINT', isn't ready: either it doesn't exist or Samba isn't mounted there"; fi
TODAY=$(date "+%F")
VOLUME="$MPOINT/truecryptvol.$TODAY.tc"
echo ">>> Going to create the TrueCrypt volume ${VOLUME}. You'll be asked for a password for the volume and few other question. The creation may take few hours."
$(dirname $0)/truecrypt --volume-type=normal --size=$SIZE_BYTES --encryption=AES --hash=RIPEMD-160 --filesystem=FAT -k "" -c "$VOLUME"
3. Verify the backup
- Boot Clonezilla as "JH Clonezilla for Samba (Safe graphic)" in a vmware image with a new, empty disk of a sufficient size
- This calls the custom Clonezilla startup script, which will mount Samba and the latest TrueCrypt volume
- Alternatively you could mount them manually:
$ cd /live/image/live; . jh-my_mounts.sh; mnt_samba && mount_truecrypt
- Partition the new, empty vmware disk via fdisk as described above
- If needed, modify the backuped partition to have the same name as the target one
- To change the disk from sda to sdb: cnvt-ocs-dev <image folder name> sda sdb
- To change the partition number, rename all the files within the image folder: $ for BKP in $(ls sda1.*); do BKPNEW=$(echo $BKP | sed "s/sda1/sda2/"); mv $BKP $BKPNEW; done
- Run restore, i.e. exit the command prompt(s), which will return you back to the Clonezilla user interface, and instruct it to restore the partition (or I might save the command for that and run it from the command line)
Summary
We have learned how to add files to Clonezilla Live and modify its boot parameters to execute a customized script, and in general how to simplify the backup/restoration process tailored to our environment - namely using an encrypted TrueCrypt volume on a remote Samba share. We've also learned how to test the backup with Clonezilla and VMware by restoring it to a virtual disk and booting it with VMware.Related resources
Clonezilla FAQ- How to restore backup manually into a mountable .img file (if partclone was used for the backup; it's similar for ntfsclone and partclone-utils can read the image directly though you'll likely need to uncompress it anyway ) - join all the parts (.aa, .ab etc.) via cat and pass that to the proper un-archiver and the result to the cloning tool
- To me it took ~ 13h to decompress an lzo-compressed image of the output size 197GB on 2-core Intel Atom 230 (1.6GHz) PC while reading from&writting to an external 5400 RPM disk
- If your image names contains "ptcl" then Partclone was used to create it
- Source/target USB disk disconnects after some time with st. like "usb 1-1: reset high speed USB device using ehci_hcd and address 2" - this is likely caused by a bug in the USB 2 driver ehci_hcd present in some old and also new (incl. some 2.6.31) kernels. See this bug and comments. The only solution I can see is to try different kernel.