NVnetbackup 1.2 (Not Veritas netbackup) - SMB Network backup System
- Files
/etc/NVnetbackup/backup.conf - Main configuration file /etc/NVnetbackup/HELP - This helpfile /etc/NVnetbackup/netbackup - The netbackup script /etc/NVnetbackup/passwd - The initial credentials file /etc/NVnetbackup/drive-key - The default location of an encrypted
backup device's key
- Directories
/etc/NVnetbackup - The NVnetbackup home directory /etc/NVnetbackup/share-config - The NVnetbackup share definitions directory /etc/NVnetbackup/local-config - The NVnetbackup local definitions directory /etc/NVnetbackup/log - The NVnetbackup log directory
Usage: ./nvnetbackup [-p|-m|-u|-b]
nvnetbackup -p
prepares a drive to be used for NVnetbackup
nvnetbackup -m
mounts all defined shares
nvnetbackup -u
unmounts all defined shares
nvnetbackup -b
runs a backup
Overview
This is a simple backup system framework written for the bash shell that is used for
backing up data in a SMB networked environment. Additionally it can also be used
for backing up local data.
The primary focus of this system is the simple selection of data to be backed up and
the security of said data. It is also very portable because it relies on common linux
tools and it's behavior is controlled entirely by a single and simple configuration file.
In my setup, I use it to backup my data to an encrypted USB 2.0 drive.
I have a few of these drives that I rotate between, depending on the day of the week.
Installation
Installation is fairly easy, all you need to do (as root) is run the "install.sh" installation
script included in the distribution and then follow the directions after it is finished.
Editing the configuration file
What exactly NVnetbackup does and how it does it is controlled entirely by the
backup.conf configuration file included in this distribution.
There are comments in the file for a reason, read them before making any changes!
It will prevent headaches. The comments in the file should give sufficient enough
explanation (for most users) that further explanation here would be reduntant.
Again, please read the entire configuration file and be sure you understand it
before you change anything.
Preparing your backup device
There are two ways to do this, with 256-bit AES encryption (recommended) and without
any encryption on the backup device. To use encryption, you will need to install
cryptsetup-luks and you will need to make sure that your kernel has the aes, dm-mod
and dm-crypt modules loaded into the kernel. Obviously using NVnetbackup without
encryption is the easiest to setup, most USB 2.0 drives come with the VFAT filesystem
by default.
While you can use VFAT with NNnetbackup, I suggest you use the same filesystem of
the server that is going to be using NVnetbackup. It's just more reliable to do so.
To prepare your backup device, you must first edit the backup.conf configuration file
and configure a few things:
ISENCRDIVE="yes"
KEYFILE="/etc/NVnetbackup/drive-key"
DMCRYPTDEV="NVnetbackup"
The settings above are found in the "Backup Device" section of the backup.conf
configuration file. The first setting "ISENCDRIVE" tells NVnetbackup that your backup
device is encrypted. It also tells NVnetbackup to use encryption when preparing devices.
The second setting "KEYFILE" tells NVnetbackup the location of your keyfile. It also
tells NVnetbackup where to save your keyfile when preparing drives. There are safety
precautions in place to ensure that you do not accidentally overwrite your keyfile but
I'd suggest that you make a few copies and keep them in a safe places, separate from each
other. You can encrypt multiple devices using the same keyfile, currently this is the only
way to use multiple encrypted backup devices witn NVnetbackup and there currently no plans
to change this. The third setting "DMCRYPTDEV" is the name of the dm-crypt drvice that
encrypts the data, this can be anything you want. The next set of options are found in the
"Backup Device Preparation" section of the backup.conf configuration file:
FILESYSTEM="ext3"
ENCRYPT="yes"
RANDOMIZE="no"
The first setting "FILESYSTEM" can be any filesystem that mkfs understands, by default it is
"ext3". This setting is required regardless of if you are using encrypted backup devices.
The second setting "ENCRYPT" tells NVnetbackup to encrypt backup devices when preparing
them for use, by default it is "yes". The third setting, "RANDOMIZE" writes random data to the
entire backup device before encrypting or writing a filesystem. This ensures that whatever was
on the device before, is gone forever.
Once you have these settings configured to your liking (the default will be fine for most people)
you can prepare a backup device with the following command:
./nvnetbackup -p
Just follow the on-screen prompts and you should have no problems.
Defining your backup scheme
There are two directories concerning what gets backed up and how,
they are the 'local-config' and the 'share-config' directories.
They are used for local content and SMB shared content respectively.
To configure a local backup, create a file called whatever.local in the
'local-config' directory (where 'whatever' is whatever you want to call it
just as long as it has the .local extension) and insert the following two
lines:
LSRCPATH="/path/to/source/content"
LABEL="CONTAINER"
"LSRCPATH" is the path to the content that you are backing up, and
"LABEL" is what you want the top-level directory on the backup device
that is going to contain the data to be named. For instance, if you
would like all of your local shares to be contained in a directory
with the name of the machine that they came from, just change "CONTAINER"
to the hostname of the machine. You can include the trailing slash in "LSRCPATH"
but beware, if you do this it will backup all the contents of that directory and
not the directory itself. This means that "CONTAINER" will contain all the files
in "content" instead of a directory called "content" that contains all of it's
respective files. To configure a backup that exists on a network share, create a
file in the 'share-config' directory maned whatever.share (where 'whatever' is
whatever you want to call it just as long as it has the .share extension) and
insert the following three lines:
SHAREPATH="//192.168.0.10/Share"
CREDENTIALS="/etc/NVnetbackup/passwd"
HOSTNAME="SERVERNAME"
SHARENAME="Share"
"SHAREPATH" is the UNC path to the share that contains the content to be backed up.
You can use either the IP address of the server or the hostname. I'd recommend that
you use the IP address to avoid any possible DNS issues (plus, it's simpler).
"HOSTNAME" is the hostname of the server that is sharing the data, this does not have
to be configured in DNS as it is not being used to reference the host on the network.
"SHARENAME" is the name of the share that the data is coming from.
"CREDENTIALS" is the path to the file that contains the username and password to use
when mounting the share. The mode on this file should be 0400 and it should be kept in
a safe place. You can have as many credentials files as you want, all shares do not have
to use the same one. The only time multiple shares can use the same credentials file is if
they have the same username and password. A credentials file only stores one username and
password. The syntax in a credentials file is very simple, it only contains two lines:
username="username"
password="password"
I suggest creating a user, local to that machine who has access to the data you are
backing up. Of course, you could always use the local administrator account for this
as well, but who really wants their local admin user/pass stored in a plain text file?
All mounted shares MUST be mounted to the same parent directory!
For example, let's say that you have a network (SMB) share called "Important-Stuff"
and that share is on a server with the hostname of "FILESERVER01" with the IP address of
10.1.1.25. You have configured the "SRCROOT" variable in the backup.conf configuration
file to be "/mnt" and you have created a passwd file named "Imporant-Stuff.passwd"
that exists in the "/etc/NVnetbackup" directory. Given this scenario, you would
create a file in the "share-config" directory named "Important-Stuff.share" that
contains the following information:
SHAREPATH="//10.1.1.25/Important-Stuff"
CREDENTIALS="/etc/NVnetbackup/Important-Stuff.passwd"
HOSTNAME="FILESERVER01"
SHARENAME="Important-Stuff"
Scheduling & Logging
This is done with the following crontab entry:
30 23 * * * /etc/NVnetbackup/nvnetbackup -b > "/etc/NVnetbackup/log/temp.log" 2>&1
This will run backups every night at 23:30 (11:30 PM)
Do not change 'temp.log' to anything else, it will be renamed when the script
is done writing to it. When it has finished writing the log, it will be renamed to YYYY-MM-DD.SEQ.log
where YYYY is the 4 digit year, MM is the two digit month, DD is the two digit day, and SEQ is the sequence
in which the log was created. This is so that if backups are run more than once a day, your logfile does not
get overwritten. You can configure how many DAYS that a log is kept by setting the "LOGLIMIT" variable in the
backup.conf configuration file. The default is 14. NVnetbackup will automatically delete the oldest logs when
this limit is reached. This does not mean that you can only have 14 separate logfiles at a time, if you have
the backup running twice a day this will produce two logs per DAY, that means that you will have 28
separate logfiles in your log directory before NVnetbackup starts deleting the oldest ones.
These logs do get big, by default rsync is run with the arguments -avv. For smaller logs you may
want to change this to -av. For no logging at all just amend the above crontab entry to:
30 23 * * * /etc/NVnetbackup/NVnetbackup -b
Logs are not required, although sometimes helpful and generally a good thing to have around.
Dependencies
To avoid any issues with executables existing in a different place on different machines
and to ensure that NVnetbackup is portable, NVnetbackup requires the full path to all
executables that are required for NVnetbackup to work to be specified in the backup.conf
configuration file. The default settings are specific to Fedora Core 4 but may work on
other distributions. Please read all comments in the backup.conf configuration file
before making any changes!
////////////////////////////// Last Update: 25 April 2006 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ musashi@nefaria.com //////////////////////////////