Backup location changes to default after upgrading to 7.0.4

Discussion in 'Installation, Update and Configuration' started by SteveITS, May 9, 2017.

  1. SteveITS

    SteveITS Tera Poster

    We upgraded our backup node from Virtuozzo 6 to 7.0.3. Backups ran OK until Friday night when I upgraded to 7.0.4 and Virtual Automator 7.0.2. Short version of the story: the backup path changed Friday. I do not see an option for the backup path in VA...I am not sure now if that was in 7.0.1 and removed, or I didn't notice it had just used the same path from v6. In VZ 6 it was a separate option from the location of the container backups, and I thought I remembered checking that path after upgrading VA.

    Per the 7.0.4 documentation:

    "By default, backups are placed in the /vz/vmprivate/backups directory. To set a different default backup directory, use the prlsrvctl set --backup-path <path> command."

    The backups are in fact now being saved to /vz/vmprivate/backups which on this server is a 100 GB partition, instead of our 4 TB backup drive (the path was /backups/vm). I changed the location and moved the files, but VA only recognizes the backups that were made in /vz/vmprivate/backups.

    So, it seems either the upgrade to 7.0.4 or the subsequent restart must have changed the location, since there were no files in /vz/vmprivate/backups before Saturday morning and backups in the old location up until Friday.

    That also explains why our Windows VM backups failed since Saturday..they are running out of space for the "initial" full backup. Since I couldn't find the error in Google or Virtuozzo's KB, the backup task failure message was "Operation is finished with errors: operation on VE "windowsVMname" failed: Cannot backup VM. The backup command for the "windowsVMname" virtual machine failed with code 255." Unfortunately we didn't get emailed an alert for that error.
    Last edited: May 10, 2017
  2. SteveITS

    SteveITS Tera Poster

    Note 1:
    After changing the backup location, backups of our Windows VM started working and backups of our (not-offically-supported FreeBSD-based) router VMs failed, with code 255 and (usually) "Cannot backup VM. Unable to access the virtual hard disk. Please make sure that there is at least 10 MB of free space on the physical server's hard disk, and you have enough rights to access the virtual hard disk." Recreating the scheduled task didn't fix it.

    Running "prlctl backup" from the command line yielded additional info:

    "(Details: No return element in drive-backup response:
    {"id":"libvirt-532605","error":{"class":"GenericError","desc":"Could not open backing file: Could not open backing file: Could not open '/vz/vmprivate/backups/{ab7966b0-ea01-486d-8a83-b5d9516663e7}/{92ba1d82-75c2-4f8b-af07-8e8060226742}/harddisk.hdd.qcow2': No such file or directory"}}

    /vz/vmprivate/backups is the old backup location. So apparently VA isn't smart enough to start a full backup in the new location if it can't find the backups in the old location, even if I moved them into /backups/vm/. And, note "prlctl backup-list" showed the old backups in /backups/vm/{ab7966b0-ea01-486d-8a83-b5d9516663e7} so it knew to look there.

    I ran a full backup manually for the VM on our backup node, and it backed up to the new location just fine.

    Note 2:
    For the other VM on a different physical server, I found running prlctl backup ___ -f backed up to /vz/vmprivate/backups. Running the backup through VA backed up to the correct "cluster" location on our backup server. "prlsrvctl info" shows the backup location on each physical node (except our backup server) is /vz/vmprivate/backups, so I can see why prlctl backup used that location, however, apparently the "-s" option needs to be specified for command line backups run on other servers, while VA backs up to the defined Backup Node.

Share This Page