Koozali.org: home of the SME Server

Legacy Forums => Experienced User Forum => Topic started by: amaeng on December 14, 2005, 04:42:37 AM

Title: mitel v5.6 backup crash......
Post by: amaeng on December 14, 2005, 04:42:37 AM

G'Day All,
We have been running a e-smith/mitel server for some time now. Please find listed below the basic hardware config for the unit:

pentiun 1-166mhz
128M ram
2 x 10G hard discs running raid 0
1 seagate STD28000N 4/8 gig DDS2 tape backup.

We were originally running e-smith 3.12 and last year upgraded to mitel 5.6.

All along the unit would occasionally (once a week) crash on backups with various error messages. The server would always restart without loss of data.

The unit recently crashed but would not re-boot. From memory the error message was "kernel panic: failed to init kernel."

I installed a fresh copy of mitel, and proceded to restore the backup.

The backup restored no data.


Here is the the log from doing a list off the tape:

|------------------------------------------------
| Reading from current tape position
|------------------------------------------------
At block 1.
|------------------------------------------------
| buffer -m 3m -s 10k -u 100 -t -p 75 -B -i /dev/nst0 | gzip -dq | restore -t \
|  -v -b 10 -f -
|------------------------------------------------
Kilobytes Out 10
restore: Tape read error on first record
Verify tape and initialize maps
Input is from file/pipe
|------------------------------------------------
At block 2.
|------------------------------------------------

We are missing a tape that was rotated, the the next previous one is a year old!!!!!

Is it possible, even thought the machine did apparently crash at the begining of the last backup, there could be valid data on the tape???

After the incident we resotred one of the older backups, so may have inadvertantly overwritten any  data on the raid array.

Has anyone got any ideas????

Cheers

Rob

listed below are the flexbackup.conf file and the script used to create the list.

flexbackup.conf


# DO NOT MODIFY THIS FILE! It is updated automatically by the
# SME Server software. Instead, modify the source template in
# an /etc/e-smith/templates-custom directory. For more
# information, see http://www.e-smith.org/custom/
#
# copyright (C) 2002 Mitel Networks Corporation
#------------------------------------------------------------


$afio_echo_block = 'false';

$afio_compress_threshold = '3';

$afio_compress_cache_size = '2';


$blksize = '10';

$mt_var_blksize = 'true';


$buffer      = 'true';  
$buffer_megs = '3';    
$pad_blocks  = 'true';  


$compress    = 'gzip';  
$compr_level = '4';    


$cpio_format = 'newc';


$device    = '/dev/nst0';

$dump_length = '0';

$dump_use_dumpdates = 'false';


$erase_rewind_only = 'true';


$erase_tape_all_level_zero = 'true';


$exclude_expr[0] = 'news/articles';
$exclude_expr[1] = '.*~$';  


$remoteshell = 'ssh';  
$verbose     = 'true';  
$sparse      = 'true';  
$indexes     = 'true';  


$logdir     = "/var/log/flexbackup";  
$stampdir = "/var/state/flexbackup";
$index    = "$stampdir/index";      
$comp_log = "gzip";                  
$prefix     = "";             
$sprefix  = "";                       
$tmpdir   = "/tmp";                  


$nocompress_types = 'mp3 Z z gz gif zip lha jpeg jpg taz tgz deb rpm bz2';


$tar_echo_record_num = 'false';

$tar_atime_preserve = 'true';


$traverse_fs = 'false';


$filesystems[0] = '/ /boot';


$type = 'dump';


flexbackup-list

cd /root/flexbackup
/bin/mt -f /dev/nst0 rewind
/bin/mt -f /dev/nst0 fsf 1
/usr/bin/flexbackup -list > /dev/null
/bin/ls-l /root/flexbackup/flexbackup.list.log
/bin/mt -f /dev/nst0 rewind
/usr/bin/pico /root/flexbackup/flexbackup.list.log

Title: mitel v5.6 backup crash......
Post by: MSmith on December 14, 2005, 05:40:19 AM

Short response:  I think you're out of luck.  If you installed a "fresh copy" of SME you have already overwritten your RAID array.  

I'd've tried booting from a Knoppix CD to see if the individual drives had recoverable data before zapping the drives and restoring from a known-unreliable backup.

I'm sorry, but I don't think you have a good backup there.  In the future, if you have to restore, I'd recommend setting aside the drives from the failed system and trying to do the restore on fresh or scratch drives so you have a hope of recovery if you don't have a good backup.