Forum ©XSIBackup: ©VMWare ©ESXi Backup Software
MenuYou are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: General matters » Details on the --on-success and --on-error options » 2021-06-16 03:58:22
How would you recommend to query the outcome of the script execution ?
I understand that the exit code is always 137 because of the kill signal used at the end of the script, and therefore cannot be used to determine if any error occurred during the execution of the script.
#2 General matters » Details on the --on-success and --on-error options » 2021-06-11 06:12:43
- Mathieu
- Replies: 3
The --on-error and --on-success arguments allow to execute/trigger other backup jobs present in the /jobs folder or external programs upon backup completion.
You can trigger a job in the /jobs folder by referencing its Id, like this:
--on-success="backupId->009" (remember to enclose between double quotes).
Or you can execute any external program present in the ESXi shell like this:
--on-success="execProg->/vmfs/volumes/datastore1/xsi-dir/my-script.sh"
[...]
Please, be aware that you can also treat external programs as if they were jobs by simply placing the script inside the jobs folder and assigning it a three digit file name. Then just call the script as if it were a regular job.
This more general approach, which has been introduced with version 11 will lead to deprecating the execProg-> switch in short. So you should place scripts inside the jobs folder and name them with a three digit string. It is recommended to name scripts 700 to 800 to better identify them when needed.
Is it possible to give parameters to a script run as the result of the --on-success or --on-error option ?
Like
--on-success="backupId->700 parameter" Or
--on-success="execProg->/path/to/my/script/my-script.sh parameter" And would it be possible to directly give a 1 line script instead of a job id or a script file name ?
Like
--on-success="backupId->rm file" Or
--on-success="execProg->rm file" #3 Re: General matters » Replica XSIBackup-DC versions » 2021-06-11 03:15:43
[...]I had already made several versions of backups, but had not seen it. I understand that the snapshot.vmsn are the versions[...]
PDC-BONDITEX-Snapshot1.vmsn PDC-BONDITEX-Snapshot2.vmsn PDC-BONDITEX-Snapshot3.vmsn PDC-BONDITEX-Snapshot4.vmsn PDC-BONDITEX-Snapshot5.vmsn PDC-BONDITEX-Snapshot6.vmsn PDC-BONDITEX-Snapshot7.vmsn PDC-BONDITEX-Snapshot8.vmsnThanks
I would like to rebound on the existence of these vmsn files in the replica folder.
I've noticed these files are created in the VM directory when a snapshot of a VM is created. They are then automatically removed from the VM directory when the snapshot is removed.
I was wondering why (c)XSIBackup-DC copies the VM-SnapshotXXX.vmsn files in the replica directory (and keeps the previous ones) each time the VM is replicated. Are these VM-SnapshotXXX.vmsn files of any use for us ?
Same question with the VM-vss_manifestsXXX.zip files which accumulate in the replica folder when we ask (c)XSIBackup-DC to quiesce the VM before taking the snapshot.
#4 Re: General matters » Does XSIBackup Pro work with ESXI 7? » 2021-06-08 03:39:59
(c)XSIBackup-DC is considerably faster than Pro Classic in almost any situation.
In our case, it was the opposite, (c)XSIBackup-DC was considerably slower.
It was one of the reasons that made us want to stick to the classic version, though deprecated, as we were still able to run it on ESXi 7 using vmkfstools as backup program (with the free version, the pro version is set up not to allow users to run it on ESXi 7).
That was until we came across this crucial piece of information from last year:
©XSIBackup-DC has two major working modes for backups and replicas: local and remote, that is: passing a local path as the third argument or passing a remote path root@a.b.c.d:22:/some/remote/path
When you use the first mode (local), the software assumes your remote site is reachable within a reasonable local latency lapse, thus it queries each individual block before actually copying it or just adding its hash in case it already exists.
When you use the remote path syntax, it changes to a different algorithm by means of which the block maps are exchanged at the beginning of the process, then it starts traversing the disks in block size chunks to check individual hash and check whether it has to be sent or not.
If you mount some remote NFS server and the latency is high (non local), then you should not be using the local mode, but the remote, so that you get the block manifest on advance and perform all checksum comparison operation locally.
When you perform a local backup to a, let's say 50 ms latency remote host, you are adding 50ms to each individual block operation. Every mode has its reason of being, you just have to choose the most suitable one in each situation.
So we unmounted our NFS and gave a remote path to our replicas. And it did allow (c)XSIBackup-DC to achieve higher speed than the classic version.
#5 Re: Speed » Intel SHA-1 extensions » 2021-04-26 07:46:39
How can we determine if our processor incorporates the extension for SHA-1 algorithm?
We have an Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz, and we can find on Intel website that this CPU incorporates the following extensions: Intel® SSE4.2, Intel® AVX, Intel® AVX2, Intel® AVX-512.
#6 Re: General matters » Does XSIBackup Pro work with ESXI 7? » 2021-04-22 02:07:18
What does it mean to read data from the SCSI disks? Is it slower than read data from the files on earlier version of ESXi?
#7 Re: Feature requests & improvements » Replica VS Backup differences » 2021-04-20 05:32:51
We were interested to implement such a method, but we felt like we needed to purchase a second license to backup the replicated VM from the passive cluster server.
Pages: 1