For quite a while, I have had a backup solution that I was not happy with. I have now remedied this. I am using a small server, a HP Proliant Microserver N40L. I tend to use Debian-based GNU/Linux systems at home. While I do eventually want my new solution to support Windows systems, it is not a priority. To support both Windows and Linux operating systems, I would use Samba. However, I have had mixed results with Samba, in home and small business settings. I am now succesfully using NFS (Network Filesystem Share) to back up computers with Linux on it. Unfortunately, NFS support under Windows isn't great. Apparently it is only supported by several Microsoft Windows Vista, Server 2008, Windows 7 Enterprise and Windows 7 Ultimate ( http://www.microsoft.com/en-us/download/details.aspx?id=2391 ). In this post I will outline how to install NFS under Debian-based operating systems, as a server and as a client. As it turns out, this is pretty simple.
The server
We will be using a volume that is mounted under
/media/backupspace
.
First, we will install the required software (I'm using apt and sudo to get the necessary packages and rights,
just substitute as necessary).
sudo apt-get install nfs-kernel-server
This install should make sure that everything required for NFS is loaded at startup.
Now we will mount this same volume in a directory that will be used by NFS.
First, we create the new mountpoint
sudo mkdir -p /exports/backupspace
and then we bind the volume, the one that we wish to place the backups on, to that new mountpoint. We can do this
manually with
sudo mount --bind /media/backupspace /exports/backupspace
To have it be mounted during startup, we can add it to the
/etc/fstab
file. This file can only be edited by a
superuser. We would add the following line:
/media/backupspace /exports/backupspace none bind 0 0
Three other files are relevant to our configuration:
/etc/default/nfs-kernel-server
/etc/default/nfs-common
/etc/exports
These three files can also only be edited by a superuser.
For this example we will not be setting up authentication requirements. You may wish to do so yourself, perhaps
after you have gotten your share accessible without authentication.
In
/etc/default/nfs-kernel-server
we will be setting
NEED_SVCGSSD=no
. This indicates that we don't need authentication.
In
/etc/default/nfs-common
we set
NEED_GSSD=no
because we are not using authentication, and
NEED_IDMAPD=yes
because we want to map user IDs from names (for properly preserving permissions). For that to work, 'idmapd' should be
running and configured properly, something that it probably does by default.
In
/etc/exports
we will indicate that we want to use our newly created /exports/backupspace. We add something like
/exports/backupspace 10.0.0.0/24(rw,fsid=0,insecure,no_subtree_check,async)
This should share /exports/backupspace, to the indicated subnet, with fairly standard settings and no authentication.
Restart the NFS service for the changes to have effect (
/etc/init.d/nfs-kernel-server restart
should do it).
The client
First, we need to determine where we will mount our network share (i.e., what path we will be using to access our files).
This can't be done in an encrypted directory. I suggest using the location
/media
to create your mountpoint in, as
this is the directory that storage devices are mounted to by the operating system itself. For this example I will be
using
/media/backupspace
to mount my networked storage.
sudo mkdir /media/backupspace
We install the client software:
apt-get install nfs-common
We can manually mount our network share using the mount command:
sudo mount -t nfs4 -o proto=tcp,port=2049 backupserver:backupspace /media/backupspace
"-t nts4" indicates that we want to access something that is shared over nfs4.
"-o proto=tcp,port=2049" are the default connection settings for the NFS service.
"backupserver:backupspace" indicates which server and which share we will be using. Note that we do not list the
server-side path here.
The last part, "/media/backupspace", is the mountpoint on our client.
If we want to have the networked share to be mounted on boot we can use fstab, as shown earlier. We will use the flags "hard,intr". To quote the NFS how-to on the "hard" setting:
"The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except by a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard,intr on all NFS mounted file systems."
( http://nfs.sourceforge.net/nfs-howto/ar01s04.html ) Since this is a backup system, it is crucial that we do not use the "soft" setting, which will lead to data corruption in such situations.
We will add something like the following to fstab:
backupserver:backupspace /media/backupspace nfs rw,hard,intr 0 0
On my backup server I also have a share that is rarely written to. That share is itself not a backup, though a backup
is created of it. Currently I mount it manually, but if I were to add it to fstab, I would have it mounted as read-only
("ro,hard,intr").
Some notes
It is worth spending some time thinking about NFS security (
http://nfs.sourceforge.net/nfs-howto/ar01s04.html
).
It is probably a wise idea to set up a firewall. You may wish to use a 'defense in depth' approach, and set up a
firewall both for your network but also specifically on your NFS server machine.
Currently I am using the
rsync
command to duplicate my files. This works fine. One downside is that there is no
solid, pre-built way to handle filename changes. This isn't really surprising, without storing metadata there is no
way to determine that a path has been adjusted. Instead, it concludes that items have been removed and that items have
been added, and starts doing the same to the target location.
If you are copying to an NTFS formatted target then it is important to know that NTFS doesn't support permissions.