Updated NFS backup script

We had a problem that when the NFS where all the backups on our network go is offline, a huge TAR is made in the root of the Linux file server. Not good!

After some searching and playing with SH (beware! different from BASH) scripts, I came up with this solution:

#!/bin/sh

/usr/bin/MountSaturnBackup
sleep 2

DT=`stat -f -L -c %T /mnt/backup`
if [ "$DT" = "nfs" ]; then
 tar cpf /mnt/backup/FullBackup.tar --same-owner --exclude=/network/backups/Jupiter --exclude=/var/cache/zoneminder/events/* --exclude=/proc/* --exclude=/media/* --exclude=/d$
fi

The correct thing to do would be to add an else statement and have the script send me an email. I'll look at that later....

DaviCAL installation

Fed up with waiting for Snow Leopard I decided to set up a calender server on our Linux server. After some searching I found out that Davical would be the best solution, especially since we use thunderbird and would like to use lightning as a calerdar client.

I installed DaviCAL on our Ubuntu 7.10 server, this was not very easy! All in all I can't even rember how I exactly did it. My plan is do to the same on a second server and document this step by step.

Most important thing for me is that is all works! There are some disadvantages, but none to big.

Some things to watch out for:

• In the permissions file of PostgreSQL (pg_hba.conf), make sure to post the access control rule at the top of the configuration document!
• The username in the caldav access URL is casesensitive!
• Use this as URL: http:////caldav.php//home/

Since DaviCAL uses PostgreSQL instead of MySQL a extra backup routine is important for me. Our MySQL database is backup, so I added an extra backup script:

#################################################################################################
# PostgresSQL Backup:
mv /network/backups/Database_Backup/Daily6_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily7_PostgreSQL_DaviCAL.sql
mv /network/backups/Database_Backup/Daily5_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily6_PostgreSQL_DaviCAL.sql
mv /network/backups/Database_Backup/Daily4_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily5_PostgreSQL_DaviCAL.sql
mv /network/backups/Database_Backup/Daily3_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily4_PostgreSQL_DaviCAL.sql
mv /network/backups/Database_Backup/Daily2_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily3_PostgreSQL_DaviCAL.sql
mv /network/backups/Database_Backup/Daily1_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily2_PostgreSQL_DaviCAL.sql
mv /network/backups/Database_Backup/Daily_PostgreSQL_DaviCAL.sql /network/backups/Database_Backup/Daily1_PostgreSQL_DaviCAL.sql

su postgres -c 'pg_dump davical' > /network/backups/Database_Backup/Daily_PostgreSQL_DaviCAL.sql
#################################################################################################

Weird Time Machine errors on Leopard Server

When I open the main GIU of the Leopard Server there's always an error pop up on the screen from Time Machine. This error states that 'a' backup malfunctioned, but all backups seem ok.

I looked through the logs and found this: (note that most backups finish ok, just some with the error below)
4/24/09 9:38:15 AM /System/Library/CoreServices/backupd[64124] Starting standard backup
4/24/09 9:38:15 AM /System/Library/CoreServices/backupd[64124] Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
4/24/09 9:38:17 AM /System/Library/CoreServices/backupd[64124] No pre-backup thinning needed: 131.4 MB requested (including padding), 187.56 GB available
4/24/09 9:38:21 AM /System/Library/CoreServices/backupd[64124] Stopping backup.
4/24/09 9:38:21 AM /System/Library/CoreServices/backupd[64124] Error: (-43) SrcErr:NO Copying /private/var/imap/user/a to /Volumes/Time Machine Backups/Backups.backupdb/Saturn/2009-04-24-093816.inProgress/83D4516C-94ED-4201-9F20-9547F53209EF/Leopard Server/private/var/imap/user
4/24/09 9:38:21 AM /System/Library/CoreServices/backupd[64124] Copied 4 files (10.7 MB) from volume Leopard Server.
4/24/09 9:38:21 AM /System/Library/CoreServices/backupd[64124] Copy stage failed with error:11
4/24/09 9:38:27 AM /System/Library/CoreServices/backupd[64124] Backup failed with error: 11

I always thought that Time Machine does not backup mail stuff, but it apparently does backup parts (useless parts) of the IMAP mail store.

The fix I'm trying is to add the /var/imap/users/ dir to the exclude list in the Time Machine preferences screen. See if this helps....

Setting up rsnapshot backup tool on Linux + NFS

Since the Mac server is now sharing it's RAID device with NFS the Linux server can now backup to this share.

Hint:
I'm always struggling to get NFS going for some reason, using the command showmount -e you will get a list of the NFS server's shares. That helps a lot!

I set up a seperate partition on the Mac server as an NFS share only to be accessed by one IP address, that is the IP of the Linux server.

The Linux server has an hourly cronjob to keep the NFS mounted, just to be sure. I placed this file in /etc/cron.hourly/MountNFS-Share Contents:
#!/bin/sh
mount 192.168.0.3:/Volumes/Jupiter-Backups /mnt/backup/

Next I added this following to /etc/crontab on the Linux server:
0 4 * * * root /usr/bin/rsnapshot hourly
50 23 * * * root /usr/bin/rsnapshot daily
40 23 1,8,15,22 * * root /usr/bin/rsnapshot weekly
30 23 1 * * root /usr/bin/rsnapshot monthly

This way the Linux server should backup itself incrementally to the Mac server's RAID device. Also, because the backup goes to the RAID device it will automaticaly be an extra off-site backup.

Installed new backup hardware

The 500GB backup disk in the Mac server is showing a SMART failure warning. So needs replacing. We also wanted a more solid offline backup method.

We placed a DeoNet RAID external USB2.0 next to the server. Backups will now be as followed:

• Mac server Time Machine will backup itself to the RAID device
• Mailbfr running on the Mac server will backup all the mail files to the RAID device
  
• The Mac server will share the RAID using separate partitions, one for the Linux server and one for Time Machine clients on the LAN
  
• The Linux server will backups its data to the shared RAID using rsnapshot and NFS
• Macs on the LAN will backup themselves using Time Machine via the Mac server on the RAID.
  

There are two 1TB discs in the RAID, configured as mirrored RAID 1. There are also two separate discs stored off site. Once every week one of these disks will be swapped with one in the RAID. The RAID will automatically update the disc.