You are not logged in.
Pages: 1
We're seeing something very troubling. Every backup says (on every .vmdk file) : "The CBT sequence has not changed since last backup"
Our command is :
/scratch/XSI/XSIBackup-DC/xsibackup \
--replica=cbt \
"VMs(clientname)" \
/destination/clientname \
--backup-how="hot" \
--config-backup \
--quiesce \
--rotate="5D"
Anyone have any idea what might be causing this ?
Thanks. Not really sure how that happened, but I indeed had a file named "VMs(newmirrors)".
Removing that solved it.
We're experiencing an issue with a single VM that we can't seem to get backed up :
(c)XSIBackup-DC replicating data to /xsibackup-dc/212-replica/newmirrors
-------------------------------------------------------------------------------------------------------------
Performing --replica action
-------------------------------------------------------------------------------------------------------------
Backup folder '/xsibackup-dc/212-replica/newmirrors'
-------------------------------------------------------------------------------------------------------------
Source is a file: VMs(newmirrors)
-------------------------------------------------------------------------------------------------------------
2022-08-07T11:05:06 | Error code 4601 at file common.c, line 4601 | Error description: path to .xsitools is empty
-------------------------------------------------------------------------------------------------------------
2022-08-07T11:05:06 | Error code 4612 at file common.c, line 4612 | Error description: can't find .xsitools file at:
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
2022-08-07T11:05:06 | Error code 216 at file signal.c, line 216 | Error description: raised SIGTERM (11) (2) in job, total errors: 11, check error.log
-------------------------------------------------------------------------------------------------------------
The command being used is :
/scratch/XSI/XSIBackup-DC/xsibackup \
--replica=cbt \
"VMs(newmirrors)" \
root@192.168.0.8:22:/xsibackup-dc/212/newmirrors \
--use-smtp="2" \
--backup-how="hot" \
--config-backup \
--mail-to="backupreports@somedomain.com" \
--quiesce \
--rotate="5D"
The /xsibackup-dc/212/newmirrors path exists but it is empty, ready to be used. File permissions are identical to other paths for VMs where backups are succeeding.
Does anyone have any idea what might be wrong ?
I'm at little lost there. My goal is to verify that the replica was succesfully made, but I want to auomate this 100%, so it runs right after a backup. Ideally I don't want to actually start the VM since that would cause IP conflicts and such.
Hi,
Is there a way to check an SSH based backup repo (made with replica=cbt) ?
I tried :
/scratch/XSI/XSIBackup-DC/xsibackup --check=full root@backup-host:22:/volume2/xsibackup-dc/TestVM
which results in :
2022-01-04T11:19:42 | Error code 3106 at file xsibackup.c, line 3106 | Error description: could not find any file or dir at /volume2
Sorry I'm mixing a few things. I'll try to be more clear :
- If we use --replica to make a complete replicate of an active VM to location A and then make a copy of that replica to location B, we can later on restore it by placing it back on a VMware host and registering the vmx file, correct ?
- If we then take a new --replica to location A and do a differential copy of that replica to location B, we have both the original version and the second one available for restoring.
At least that's what we're trying to accomplish...
When you do --replicate of the VM, do you need to turn it off first ? I thought it took a snapshot, then made a backup of that snapshot ? Since we're doing an rdiff-backup of the replicated VM, would that not be safe ?
Thanks for your very thorough responses. I believe we've found a workable solution based on your previous suggestion :
- We do a replication using --replicate
- We use rdiff-backup to make a rsync-like copy of this replicated VM (rdiff-backup uses rdiff, just like rsync does) over SSH. The advantage is that we can then restore previous versions of the replicated VM
- This seems to work efficiently, with speeds hitting up to 250Mbit/sec over a Wireguard VPN connection from Belgium to Germany.
Does the above make sense to you as a backup strategy ?
Thanks for your help. Could you explain that last part ? How do you store XSIBackup respositories in a -flat.vmdk file ?
Each repository is for a single VM. The largest VM is currently 150GByte, most are around 60GByte.
We're not rsyncing at this point, we're using Bacula. When taking the backup, the IO wait on the Synology goes to 20-30%.
Probably I just don't understand how file systems work, but I was wondering if there's a straightforward way to store all file attributes in the directory cache permanently, so that it doesn't have to retrieve that information from disk. The machine we're using has 64GByte of memory of which over 40GByte is available.
We have a DS1621+ with 6 Western Digital WD Red Plus NAS disks in RAID 10 with an ext4 volume. Our impression is that it has trouble searching through the directory structure extremely fast, taking 80 minutes for a "find" in a single XSIBackup-DC VM directory (we have 1 per VM).
It seems even doing that won't cut it. The brand new Synology just isn't fast enough to scan through all the directories that result from the XSIBackup-DC run.
Is there any way to reduce the number of files, even if that increases the amount of data per incremental backup ? Since most of our environments have little daily change, we'd be ok with that.
To clarify a bit more : the initial full backup is 85Mbit/sec, the incremental runs at 10-20Mbit/sec. As far as I can tell most of the time is spent scanning the millions of files on the file system :-/
We're looking at different ways of making off-site backups of the snapshots that XSIBackup-DC produces.
In the past we tried using rdiff-backup to make sure we didn't have to copy all the data every time, but this started becoming too slow.
Recently we switched to Bacula with daily incremental backups. Sadly it seems the large number of files that XSIBackup-DC produces is what causes the most I/O wait, meaning the backup speed (from a Synology with a 10Gbps network adapter on a 10Gbps network with MTU set to 9000) is about 85Mbit/sec.
Does anyone have suggestions on the best way to make off-site backups of the snapshots ?
Perfect, thanks a lot !
It seems there's a file called var/log/backupdb.log that contains data about which backups were made.
Is there any documentation on the fields of this csv file ?
Is there any way to retrieve when a VM was last backed up ? We'd like to add this to our monitoring. If a VM hasn't been backed up for x amount of time, it would show up red and send an alert.
We have "--backup-room=700" as part of our job command, so I think it just does that automatically.
Would there be a better approach for this ?
It seems to me that, once you hit the limit for each repo, it will prune after almost every backup, so the warning will appear every single time ?
When pruning with XSITools, the subject of the backup becomes 'some warnings were raised', although the only warnings are about the fact that the repo was pruned.
Since this is the goal, shouldn't this just be an information level thing, instead of a warning level ? Now it look as if something is wrong ?
Pages: 1