[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Unexpected backups
From: |
Busser, Jim |
Subject: |
Re: [Gnumed-devel] Unexpected backups |
Date: |
Fri, 9 Aug 2013 17:21:24 +0000 |
On 2013-08-09, at 2:10 AM, Karsten Hilbert <address@hidden> wrote:
>> ...
>> I discovered via sudo ls -al in
>>
>> /var/lib/gnumed/server/backups
>> … (backups)
>
> Installing the Debian server package helpfully creates a
> cron job for you running once per day:
>
> /etc/cron.daily/gnumed-server
>
> That script first runs the backup script and then the
> zip+sign script. Both will read configuration from
>
> /etc/gnumed/gnumed-backup.conf
>
> Setting the database name to "" will render dysfunctinal
> (all !) runs of the backup script.
I can understand how the directory would have contained just a few backups, on
account of the VM hibernating during periods of suspension.
However, I would have thought that since apt-get install <server> does not
itself create any GNUmed db, then can have existed no v18 to backup until I
would have bootstrapped it, at which point it should have immediately contained
the test data, which should have made it larger.
Therefore I am just a bit disquieted by being unable to account for why an
appropriate size backup did not happen until I ran the backup command manually?
The cronfile is as would be expected, I think:
======================
#!/bin/sh
# care for daily backup of GNUmed database
# This script only saves plain data without table structure etc.
# Normally you want to store the whole database
# DATA=/usr/sbin/gm-backup_data
# Backup of data and table structure
DATABASE=/usr/sbin/gm-backup_database
# Compress and sign backup
ZIPSIGN=/usr/sbin/gm-zip+sign_backups
# if [ -x "$DATA" ] ; then
# $DATA
# fi
if [ -x "$DATABASE" ] ; then
$DATABASE
fi
if [ -x "$ZIPSIGN" ] ; then
$ZIPSIGN
fi
=========================
-- Jim