Offsite backup with iSCSI

If you have a remote server (such as a VM, Amazon instance, etc) with a bit of spare storage, you could use it as remote backup. It'll be quite slow (dependent on your internet connection speed), but you can just automate backups, and then it doesn't really matter.

In order to make your remote server's disks available to your local machine, there are a lot of ways of doing it.
You could use FTP, SMB, NFS, or SSHFS which all work with an existing filesystem.
If you want to have the raw storage to use, a popular and simple one is NBD.
As you might have guessed from the title, we're going to use iSCSI though.
In iSCSI terminology, the client initiates the connection (so is called the Initiator), and the remote server with the disks is the Target.

We'll use iscsitarget for the target, and iscsi-initiator-utils as the initiator. Install them using your favourite package manager.

First thing is to carve up some disk for use as your remote storage.

server# lvcreate -L 100G -n offsite vg00

Then add it to your /etc/ietd.conf like this:

Target iqn.2015-12.tld.yourdomain:offsite
	Lun 0 Path=/dev/mapper/vg00-offsite,Type=fileio,ScsiId=xyz,ScsiSN=xyz

and restart it.
You might see some errors regarding kernel networking parameters. Don't worry about them now. You can experiment with them to make it faster later.

Now on the client, we need to connect to the target. First thing we need to do is discover the targets.

client$ iscsiadm --mode discoverydb --type sendtargets --portal remote.ip.address --discover

This should display the target:

remote.ip.address:3260,1 iqn.2015-12.tld.yourdomain:offsite

Put the whole thing in /etc/iscsi/initiatorname.iscsi prefixed with InitiatorName= e.g.

InitiatorName=remote.ip.address:3260,1 iqn.2015-12.tld.yourdomain:offsite

and restart iscsi.

/etc/init.d/iscsi restart

Your remote storage should now appear in /dev/disks/by-path/

client# ls /dev/disk/by-path/ip*
/dev/disk/by-path/ip-remote.ip.address:3260-iscsi-iqn.2015-12.tld.yourdomain:offsite-lun-0

From this point, you can now create a filesystem on it (mkfs), mount it, and use it as a normal local filesystem.

client# mkdir /mnt/remote
client# mkfs.ext4 -m 0 /dev/disk/by-path/ip-remote.ip.address:3260-iscsi-iqn.2015-12.tld.yourdomain:offsite-lun-0
client# mount /dev/disk/by-path/ip-remote.ip.address:3260-iscsi-iqn.2015-12.tld.yourdomain:offsite-lun-0 /mnt/remote
client# ls /mnt/remote/

Caveats

I would advise using LUKS to encrypt the storage on the client, so that the only data that's transferred and stored remotely is encrypted.
Standard network sense is also advised. I'd recommend running a VPN (such as OpenVPN) between the server and the client, and binding ietd to a non-public IP address. At the very least, firewall the port that ietd uses to only allow access from your client IP. You don't want other people on the internet scanning for, and finding your nice free storage, or being able to exploit any buffer overflows in the ietd daemon.

LUKS

So you think that encryption is probably a good idea for your remote offsite backup.
I'm assuming that you have your remote storage device available locally, and unmounted. First we want to format it for LUKS use.

client# cryptsetup -y -v luksFormat /dev/disk/by-path/ip-remote.ip.address\:3260-iscsi-iqn.2015-12.tld.yourdomain\:offsite-lun-0

This will ask for a passphrase twice, and set it up for use with LUKS. Now you can use it.
In order to make it available via the device-mapper, run:

client# cryptsetup luksOpen /dev/disk/by-path/ip-remote.ip.address\:3260-iscsi-iqn.2015-12.tld.yourdomain\:offsite-lun-0 offsite

Now the encrypted device is available at /dev/mapper/offsite.
All you need to do now is make a filesystem on it.

client# mkfs.ext4 -m 0 /dev/mapper/offsite

and you can mount it and start using it.