Backup config file every night automatically!

[Bidule0hm]

It's in the .system hidden dataset ;)

 

[Glorious1]

It's in the .system hidden dataset ;)

It shows when I do 'zfs list', but I can't navigate to it or see it with ls -la or find it. What am I doing wrong?

Code:

[jim@Tabernacle ~]$ cd /mnt/Ark/.system
-bash: cd: /mnt/Ark/.system: No such file or directory

[jim@Tabernacle ~]$ ls -la /mnt/Ark
total 159
drwxr-xr-x  10 root     wheel      10B Jul 13  2015 ./
drwxr-xr-x   4 root     wheel     120B Jan 20 14:12 ../
drwxr-xr-x   9 root     wheel      12B Feb  8  2015 .freenas/
drwxrwx---  11 jim      staff      15B Jan 31 15:23 Attic/
drwxr-x---   7 jim      wheel      16B Feb  6 07:45 Jim/
drwxr-x---  11 jim      wheel      15B Feb  6 06:16 Media/
drwxr-xr-x   6 shuling  staff       8B Dec 29 12:02 Shuling/
drwxrwx---   4 jim      nogroup     7B Feb  6 12:40 TM-Jim/
drwxrwx---   4 shuling  staff       7B Feb  5 18:33 TM-Shuling/
drwxr-xr-x  10 root     wheel      10B Dec 12 14:57 jails/

[jim@Tabernacle ~]$ sudo find /mnt/Ark -name ".system" -print
Password:
[jim@Tabernacle ~]$

 

[joeschmuck]

If you are not making frequent changes to your configuration, you should make a manual backup to some other device, like for me my configuration is on my main computer for easy recovery if I need to build up another boot device.

 

[nojohnny101]

hey all
thanks for everyone's contributions. Thanks to more than a couple of people on here (@cyberjock @joeschmuck etc) I now have my config file backuped up safely overnight...I combined some of the commands and come up with a readable date along with there version number being attached to the file name:

cp /data/freenas-v1.db "/mnt/tank/`date \+%c`_`cat /etc/version | cut -d'-' -f2`.db" && find /mnt/tank/ -mtime +90 -exec rm {} \;

this command keeps the files for 90 days and then deletes them and I think all is working fine but I am getting a slight issue with permissions.

I get an error from the cron job saying "/mnt/tank/ permission denied" I can confirm that it is saving the .db file correctly but it doesn't seem to be able to execute the second part of the command about scanning to delete anything older than 90 days.

Any ideas? here are my permission on the said directory:
drwxrwxrwx
(as you can see i even modified the directory to chmod 777) but it still returns the error?

 

[KevinM]

hey all
thanks for everyone's contributions. Thanks to more than a couple of people on here (@cyberjock @joeschmuck etc) I now have my config file backuped up safely overnight...I combined some of the commands and come up with a readable date along with there version number being attached to the file name:

cp /data/freenas-v1.db "/mnt/tank/`date \+%c`_`cat /etc/version | cut -d'-' -f2`.db" && find /mnt/tank/ -mtime +90 -exec rm {} \;

this command keeps the files for 90 days and then deletes them and I think all is working fine but I am getting a slight issue with permissions.

I get an error from the cron job saying "/mnt/tank/ permission denied" I can confirm that it is saving the .db file correctly but it doesn't seem to be able to execute the second part of the command about scanning to delete anything older than 90 days.

Any ideas? here are my permission on the said directory:
drwxrwxrwx
(as you can see i even modified the directory to chmod 777) but it still returns the error?

Your zpool is named tank, correct? If the copy command succeeds (&&), and why wouldn't it, then this runs:

find /mnt/tank/ -mtime +90 -exec rm {} \;​

which sure looks to me like it is going to recursively delete all files in your zpool older than 90 days. I'm assuming this is not what you want.

Personally I would copy the backups to a dedicated dataset, /mnt/tank/dbbackups (for example), then run the find command within that scope...

find /mnt/tank/dbbackups -mtime +90 -exec rm {} \;
​

 

[nojohnny101]

Hello,
Sorry Kevin, you're right. I changed some parameters in the command i posted above for posting on the internet.

the second part of the command does read:
find /mnt/tank/dbbackups -mtime +90 -exec rm {} \;

it seems the permissions on the .db files being generated are not letting the operation delete them if necessary. i just checked the permission on one of the backed up confirmation files and they are:
-rw-r-----

would this be an issue with "setfacl"?

 

[KevinM]

Hello,
Sorry Kevin, you're right. I changed some parameters in the command i posted above for posting on the internet.

the second part of the command does read:
find /mnt/tank/dbbackups -mtime +90 -exec rm {} \;

it seems the permissions on the .db files being generated are not letting the operation delete them if necessary. i just checked the permission on one of the backed up confirmation files and they are:
-rw-r-----

would this be an issue with "setfacl"?

What owner and permissions are configured for this dataset? Just set the owner to be that of the user that is running the backup script and you should be fine.

I would also consider doing away with spaces in the names of your backup files. Your life will be simpler if you don't have to work around them.

[root@freenas] ~# echo `date \+%c`_`cat /etc/version | cut -d'-' -f2`.db
Sat Feb 20 23:56:30 2016_9.3.db

[root@freenas] ~# echo `date \+%m%d%Y_%H%M%S`_`cut -d'-' -f2 /etc/version`.db
02202016_235634_9.3.db


​

 

[nojohnny101]

Hello,

[root@freenas] ~# echo `date \+%c`_`cat /etc/version | cut -d'-' -f2`.db
Sat Feb 20 23:56:30 2016_9.3.db

sorry for probably the simplistic question but I don't see the difference in your revised code. maybe because of the font formatting on the forum but i don't see how you eliminated the spaces.

the dbbackups is just a directory on the dataset owned by root. that is what i don't understand because the cron job is running as root. the permissions for the whole dataset are:
owner:root
group:wheel

 

[KevinM]

sorry for probably the simplistic question but I don't see the difference in your revised code. maybe because of the font formatting on the forum but i don't see how you eliminated the spaces.

the dbbackups is just a directory on the dataset owned by root. that is what i don't understand because the cron job is running as root. the permissions for the whole dataset are:
owner:root
group:wheel

Do you see any spaces in 02202016_235634_9.3.db?

[root@freenas] ~# echo `date \+%m%d%Y_%H%M%S`_`cut -d'-' -f2 /etc/version`.db
02202016_235634_9.3.db

What are the permissions on the dataset? By default it should be owner root, group wheel, permissions 755. If so your script should work.

 

[nojohnny101]

hey @KevinM
yep my dataset permissions are exactly like your screenshot. no problem there.

sorry i didn't know you were posted my original code above your revised code. i have put in your code now and it still is returning spaces and now i get an error on the cron job that reads:

/mnt/tank/backupconfig.sh: +%m%d%Y_%H%M%S: not found

??

 

[cyberjock]

Personally, I wouldn't worry about trying to clear the 90 day thing. If you had a backup of your config file for every day since Jan 1, 1970, it wouldn't even be 5GB. If you are using compression (which the default is lz4) then the used space will be even less.

Why even concern yourself with such minuscule problems?

 

[nojohnny101]

@cyberjock

yea i think that is what i'm going to do at this point.i read your post earlier in this thread how you have a couple of years worth and it is not even 1gb yet. i think that is what i'll do.

btw i just went through your noobie presentation, thanks for taking the time to create that!

 

[Yatti420]

If you get board you can go in and clear a few months (or years) out or so.. Depends what you've done.. How active server is etc..

 

[somepsychoguy]

I was able to change the script to

cp /data/freenas-v1.db /mnt/*volume*/ConfigBackups/`date \+%Y\%m\%d`_`cat /etc/version | cut -d'-' -f2`_`cat /etc/version | cut -d'(' -f2`.db

But it outputs 20160324_9.10_2def9c8).db.
Is there a way to remove the ")"?

 

[hervon]

The latest version of 9.10 broke the script for me as well as a cron job. Something to do with the version name in /etc/version. I finally achieved the same naming (example : 20160328_9.10_201603252134.db) with this slightly modified version:

cp /data/freenas-v1.db /mnt/NASHD/BKConfigfile/`date \+%Y%m%d`_`cat /etc/version | cut -d'-' -f2`_`cat /etc/version | cut -c21-32`.db

 

[fta]

I use a small python script to do this:

Code:

#!/usr/bin/env python

import os
import shutil

VERSION_FILE = '/etc/version'
DB_FILE = '/data/freenas-v1.db'
BACKUP_DIR = '/mnt/storage/backup/freenas_config'

version = open(VERSION_FILE, 'r').read().strip()
backup_name = '%s.db' % version.replace(' ', '-').replace('(', '').replace(')', '')

shutil.copyfile(DB_FILE, os.path.join(BACKUP_DIR, backup_name))

IMO, it's easier to understand, less prone to being broken by changes in /etc/version, and names the file in a more descriptive way. You end up with a file like this:

Code:

FreeNAS-9.10-STABLE-201603252134-412fb1c.db

This python script will overwrite any existing file of the same name, which is fine because I set up automatic zfs snapshots to keep old versions.

I then use the following cron to back it up to dropbox:

Code:

/root/bin/dropbox_uploader.sh -f /root/.dropbox_uploader -q upload /mnt/storage/backup/freenas_config FreeNAS/Backups

dropbox_uploader can be found here: https://github.com/andreafabrizi/Dropbox-Uploader

 

[Wolfeman0101]

I had this running as a cron job but it broke in 9.10. I'm not sure what is broken though because I'm not getting an error message and I can't find any logs. Anyone got any ideas? Also my config file that's getting emailed is 344KB which seems larger than expected.

Code:

#!/bin/sh

### Parameters ###
logfile="/tmp/config_backup_error.tmp"
tarfile="/tmp/config_backup.tar"
filename="$(date "+FreeNAS_Config_%Y-%m-%d_%H-%M-%S")"
email="email@gmail.com"
subject="Config Backup for FreeNAS"

if [ "$(sqlite3 /data/freenas-v1.db "pragma integrity_check;")" == "ok" ]
then
### Send config backup ###
    cp /data/freenas-v1.db "/tmp/${filename}.db"
    md5 "/tmp/${filename}.db" > /tmp/config_backup.md5
    sha256 "/tmp/${filename}.db" > /tmp/config_backup.sha256
    cd "/tmp/"; tar -cf "${tarfile}" "./${filename}.db" ./config_backup.md5 ./config_backup.sha256; cd -
    uuencode "${tarfile}" "${filename}.tar" | mail -s "${subject}" "${email}"
    rm "/tmp/${filename}.db"
    rm /tmp/config_backup.md5
    rm /tmp/config_backup.sha256
    rm "${tarfile}"
else
### Send error message ###
    (
        echo "To: ${email}"
        echo "Subject: ${subject}"
        echo "Content-Type: text/html"
        echo "MIME-Version: 1.0"
        echo -e "\r\n"
        echo "<pre style=\"font-size:14px\">"
        echo ""
        echo "Automatic backup of FreeNAS config failed."
        echo ""
        echo "The config file is corrupted!"
        echo ""
        echo "You should correct this problem as soon as possible."
        echo ""
        echo "</pre>"
    ) >> "${logfile}"
    sendmail -t < "${logfile}"
    rm "${logfile}"
fi

 

[stuckj]

My cron job also broke after upgrading to 9.10. After a little investigation, I determined this is because the version file (/etc/version) added a build code in parentheses at the end of the version. It's separated by a space which is what broke the script since it's generating the filename without quotes. I fixed this with the modification below which just changes any space in /etc/version to an underscore:

Code:

cp /data/freenas-v1.db /mnt/root-dataset/raid_array/backups/freenas-phys-config/`date +%Y%m%d`_`cat /etc/version | cut -d'-' -f2`_`cat /etc/version | cut -d'-' -f4 | sed -e 's/ /_/'`.db

Alternatively, if you want the filename to be the same as it was in 9.3 (without the build version), you can use this to chop the build number off entirely.

Code:

cp /data/freenas-v1.db /mnt/root-dataset/raid_array/backups/freenas-phys-config/`date +%Y%m%d`_`cat /etc/version | cut -d'-' -f2`_`cat /etc/version | cut -d'-' -f4 | cut -d' ' -f1`.db

Personally, I like having the build number in the filename so it's a full representation of the build version in /etc/versions.

 

[Spearfoot]

The update from 9.3 to 9.10 didn't break my configuration backup script, but I didn't want spaces or parentheses in the filename. So I followed @stuckj's lead and modified my script to strip the parentheses and replace the spaces with a '-'. The script works on both 9.3 and 9.10. On 9.10 the filenames look like this ('boomer' is the host name):

boomer-FreeNAS-9.10-STABLE-201605240427-64fcd8e-20160530093727.db

On 9.3 the filename looks the same, except it lacks the 7-digit hex build number.

Code:

#!/bin/bash

# The source FreeNAS configuration database file:

SRC_FILE="/data/freenas-v1.db"

# Form the destination filename:

DEST_DIR="/mnt/tank/sysadmin/config"
DEST_HOST=$(hostname -s)
DEST_VERSION=$(cat /etc/version | sed -e 's/ /-/' | sed -e 's/(//' | sed -e 's/)//')
DEST_DATE=$(date +%Y%m%d%H%M%S)
DEST_FILE="$DEST_HOST"-"$DEST_VERSION"-"$DEST_DATE".db

echo "Backup configuration database file: $DEST_FILE"

# Copy the source to the destination:

cp "$SRC_FILE" "$DEST_DIR"/"$DEST_FILE"

# Remove prior versions in the destination directory that are 90 days old or older:

$(find "$DEST_DIR" -mtime +90 -name "*.db" -exec bash -c 'rm {}' \;)

 

[dcplaya]

Looks like the newer versions of FreeNAS break the script. The /etc/versions has a space in it and FreeNAS thinks I am trying to copy to a different directory. To fix it, made the following modification

Code:

DESTFILE=${DESTDIR}/freenas-$(cat /etc/version | cut -d'-' -f2)_$((cat /etc/version | cut -d'-' -f4) | sed 's/\ /_/g')_$(date +%Y%m%d%H%M%S).db