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 vg00Then 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=xyzand 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 --discoverThis should display the target:
remote.ip.address:3260,1 iqn.2015-12.tld.yourdomain:offsitePut the whole thing in /etc/iscsi/initiatorname.iscsi prefixed with InitiatorName= e.g.
InitiatorName=remote.ip.address:3260,1 iqn.2015-12.tld.yourdomain:offsiteand restart iscsi.
/etc/init.d/iscsi restartYour 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-0From 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/
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.
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-0This 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 offsiteNow 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/offsiteand you can mount it and start using it.