Results 1 to 3 of 3

Thread: zmanda lvm backup fails with mysql located in "/mysql"

  1. #1

    Default zmanda lvm backup fails with mysql located in "/mysql"


    with mysql's data area located under /mysql, snaphot-based lvm backup fails (and possibly other backup strategies aswell?!).

    the problem occurs when zmanda attempts to create symlinks during backup and the symlink for "mysql" database clashes with the symlink created for the root directory of the data-area tree (in our case named "mysql"):

    *** zmanda errors ***
    ln: creating symbolic link
    File exists
    dailyrun:backup:WARNING: Snapshot failed as copy failed
    dailyrun:backup:ERROR: Unable to use snapshot for mysql

    note that the ln output above does not make it to the zmanda logs since this error is not caught. to see this error you need to run the backup in the terminal.

    this is where zmanda fails:
    $ grep -A 5 -B 5 'ln -s'
    my $srcFile = $_[1];
    my $trgtDir = $_[2];
    my $r;

    mkpath( $trgtDir );
    my $cmd = "ln -s $srcDir/$srcFile $trgtDir";
    $r = system( $cmd );

    return $r;

    is there a way around this? we do not want to rename our directory root.

    kindest regards

  2. #2


    What type of backup it is, local OR remote…?
    By which user you are performing a backup, "mysql" or any other user..?
    ZRM prefers "mysql" user.

    Can you post o/p of “ls -al /mysqlbkp/dailyrun”.
    Make sure that, whole path “/mysqlbkp/dailyrun” is owned by mysql:mysql.

    For better messages backup can be performed by using "--verbose" option.

  3. #3



    backup is done locally by mysql user. zmanda is being run with verbose=1. i cannot access these servers today so i cannot post the output of ls back to you.
    however, i dont think it matters. what happens is the following:

    in the main directory of the backupset (e.g. dailyrun/<backupdate>/) you have the backup_data directory. this directory contains:
    a) a directory tree corresponding to the directory tree where mysql resides in the file system. (in our case "/mysql")
    b) one directory for each database (including "mysql).
    c) possibly some other stuff...

    when zmanda tries to create the directory for the database "mysql" it clashes with the directory created for the data residing under "/mysql". this is what ln complains about. after the backup is done it is also easy to see that a half-finished but failed directory tree exists for the backup set. in the "mysql" directory we have the "filesystem-mysql-directory", but the "database-mysql-directory" is missing.

    to me it seems that you cannot name the main directory of the mysql data partition to the same name as one of the databases in the server you are backing up or zmanda will fail.

    is this a known/unknown bug or is it possible to configure your way out of it?


Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts