[rt-users] Couldnt open File 'sessions.MYI' in /opt/rt3/var/session_data

[Robert Long]

Hey all,

So there are a number of ways you can handle this - either take a 'cold
backup' of the database, ie just copy/tar/zip all the data files off
somewhere, mind you to do this you will need to either shutdown the
database or ensure no updates take place (lock the tables).  Or you can
take the mysqldump, though it is slower and will lock the tables its
dumping so you won't be able to update them anyhow.   If you can spare
the time (or are doing it from a slave), I highly suggest doing the
former option.   Restoring one table out of a tarball is way easier than
sorting through a huge dump file (unless you're running innodb all in
one file...).

if doing a dump, you might not want the username/password on the command
line ... I suggest running mysqldump with "--defaults-file=<somefile>" (
as the first arguement, gets pissy otherwise) and having the contents of
<somefile> look like:

[mysqldump]
user=rtdumper
password=alice_bob

You should adjust the permissions on that file to deny world reading..

you can also just pipe the mysqldump to gzip/bzip2, this will make it
much faster... eg: mysqldump <options> | bzip2 -9 > mysqldump.bz2.

You should also set your umask to at least 007 before hand, as creating
a dump / backup of your database world readable kinda defeats the
purpose of the database permissions....

Another trick is if you're only going to keep a weeks worth of backups,
just use the day of week when creating the file, then you don't have to
worry about rotating them (and mentally set $AmbiguousDayInPast to 1...)

just some random thought...
.r'

Scott Hill wrote:
> On 7/18/07 5:58 PM, "John Schubert" <johnschubert at yahoo.com> wrote:
>
>   
>> Now to go back and do the
>> tutorial on DB back up and do it myself, and then
>> figure out how to automate pushing it to another place
>> on an all Microsoft shop (on which I have no
>> permissions anywhere).
>>     
>
> I just had to figure this out myself. Here's the script I worked up, with
> some help from the wiki. Cron kicks it off every night. It's been running
> correctly for a few days...
>
> I'm no shell scripting expert, and there's no error catching whatsoever
> right now. All the usual warnings apply: no guarantees, no warranties, YMMV.
> And of course, everyone, feel free to tell me exactly where I made horrid
> mistakes!
>
> ----- CUT HERE -----
> #!/bin/bash
> #
> # rtbackup.sh
> # Backup RT database & config files
> # Scott Hill, 7/16/2007
> # Based in part on backupRT.sh by Michael Erana
> #   (http://wiki.bestpractical.com/view/backupRT)
>
> #
> # Script Variables
> #
> SCRTMPDIR=/etc/request-tracker3.6/backup
> dumpfile=rtdb-`date +%Y%m%d`.sql
> rtdbuser=rtuser
> rtdbpwd=password
> rtdbname=rt
> backupshare=//server/share
> backupmountpoint=/mnt/server
> shareuser=username
> sharepass=password
> backupdir=/mnt/server/backups
> backupfn=rtbackup.zip
>
> #
> # Mount backup target volume
> #
> smbmount $backupshare $backupmountpoint -o
> username=$shareuser,password=$sharepass
>
> #
> # Make/Verify target dirs
> #
> if [ ! -d $backupdir ]; then
>   mkdir $backdir;
> fi
>
> if [ ! -d $SCRTMPDIR ]; then
>   mkdir $SCRTMPDIR;
> fi
>
> # 
> # Rename any existing files, keeping a week's worth of files
> #
> rm $backupdir/$backupfn.6
> mv $backupdir/$backupfn.5 $backupdir/$backupfn.6
> mv $backupdir/$backupfn.4 $backupdir/$backupfn.5
> mv $backupdir/$backupfn.3 $backupdir/$backupfn.4
> mv $backupdir/$backupfn.2 $backupdir/$backupfn.3
> mv $backupdir/$backupfn.1 $backupdir/$backupfn.2
> mv $backupdir/$backupfn $backupdir/$backupfn.1
>
> #
> # MySQL dump
> #
> mysqldump --opt --add-drop-table --single-transaction -u $rtdbuser \
> -p$rtdbpwd $rtdbname > $SCRTMPDIR/$dumpfile
>
> #
> # Zip up the dumpfile and the /etc/request-tracker3.6 dir
> #
> zip -9 $backupdir/$backupfn $SCRTMPDIR/$dumpfile /etc/request-tracker3.6/*
>
> #
> # Cleanup
> #
> rm $SCRTMPDIR/$dumpfile
> smbumount $backupmountpoint
>
> ----- CUT HERE -----
>
>
>