You are not logged in.
Pages: 1
I can confirm that [b]XSIBackup-DC 1.5.0.7[/b] solved the segmentation fault issue.
I will keep that host monitored for a couple more days.
You are right. That was not only a way to suggest to make the cli syntax more readable, but also a call to split code.
Instead of a monolithic "xsibackup" binary, a master, light binary "xsibackup", o shorter "xsi" with real commands implemented in ad hoc binaries.
Not a new idea at all. Just to make life easier to developers and new users.
For instance:
xsi repo unlock --root=/vmfs/volumes/nfs03/replica --forcewould run "bin/xsi-repo" binary with command "unlock" and "--root=/vmfs/volumes/nfs03/replica --force" options.
After removing the lock file from VM's target replication directory, I could successfully replicate it with xsi 1.5.0.3.
But after upgrading to xsi 1.5.0.6, last night the segmentation fault appeared again.
To switch to CBT-based replication, for further testing, do I need to clear the target replication directory, or not?
Download link warns registered users to download XSIDirector from their user page, but I can't find such link as a logged-in user.
I guess not. We moved PB of VM-related data for years between multiple 2- or 4-pathed iSCSI backed datastores and never lost a byte.
I found the [b].locked[/b] file. Thanks.
In the meantime
./xsibackup --check=full /vmfs/volumes/san03/vm42finished, wrote that all replicated files are OK, but then it wrote [b]Segmentation fault[/b] again and terminated:
SIGTERM (11) condition was trapped: check logs for more details
Cleaning up...
Segmentation faultLogs contain no more error info than what is written to the terminal.
xsibackup --check[=fast|full] [--run-mode=background] --mail-to[=some@email.com] /path/to/repository
xsibackup --repair [--run-mode=background] --mail-to[=some@email.com] /path/to/repositoryShould detach from terminal, perform the check in background, and email a report about the check/repair.
I double checked permissions, but they seem OK.
Replication target path is on a VMFS datastore connected to a multipathed iSCSI target.
I just found the source of a recurring error in one of my jobs.
[b]xsibackup --replica[/b] terminates with [b]Segmentation fault[/b] on a large VM (about 7.5TB). On next run, job terminates immediately with [b]*** Remote directory is locked ***[/b].
[b]xsibackup --repair[/b] doesn't seem to work.
[b]./xsibackup --check=full /vmfs/volumes/san03/vm42[/b] is running just now.
Now how do you get out of that corner? Can XSI Backup handle VMs as large as that one?
Talking of usability and readability - maybe for xsi 2.0 or even xsi 3.0 - what about a redesigned command line with object-action pattern in mind?
xsi help
xsi host backup --file=/vmfs/volumes/nfs03/vmhost021-esxi-cfg-20210511.tgz
xsi vm backup --repo=/vmfs/volumes/nfs03/backup
xsi vm replica --repo=/vmfs/volumes/nfs03/replica --names=server01,server02,server03 --quiesce
xsi repo check --root=/vmfs/volumes/nfs03/backup
xsi repo repair --root=/vmfs/volumes/nfs03/backup
xsi repo unlock --root=/vmfs/volumes/nfs03/replica --force
xsi config add-key
xsi config export --file=/vmfs/volumes/nfs03/xsibackup-cfg-20210511.zipet cetera.
Thanks.
That worked, but my feature request was for usability and readability.
Chores like that one are the source of many mistakes due to hurry, poor understanding of command line etc. Prevention is better than cure.
Sorry, I meant provide a new action to [b]xsibackup[/b] to "fire and forget" a job interactively.
Maybe, **--queue** is not the right name. What about **--run**?
xsibackup --run 000[b]xsibackup[/b] should run in background and detach from the terminal.
Please, make the logs (more) readable/usable:
[list=*]
[*]remove ANSI codes[/*]
[*]make entries terse and avoid unnecessary decorations[/*]
[*]add proper UTC timestamps to each entry[/*]
[*]add option to have per-job log files[/*]
[/list]
Please, add a [b]--queue[/b] action to queue an existing job for execution:
./xsibackup --queue 000[b]xsibackup[/b] should go in background and detach from tty.
After ESXi host rebooted, next xsibackup run completed and sent its e-mail report.
I created the [b]cfgbak[/b] directory and, after last run of xsibackup, at least one replication job created the compressed archive with ESXi configuration data.
After I ran "hash -r" yesteday, today I
- checked the replicated VM: [b]OK[/b]
- checked the xsibackup.log: [b]OK[/b], but contains again "[ins]SIGTERM (11) condition was trapped: check logs for more details[/ins]"
- checked --mail-to mailbox: [b]NOK[/b], it does not contain a report for last night run
I [b]can[/b] reboot ESXi host where XSI shows this behavior.
VMkernel vmhost01.mtka.eu 6.5.0 #1 SMP Release build-17477841 Jan 17 2021 19:24:58 x86_64 x86_64 x86_64 ESXi
In --replica jobs with --config-backup, replication is performed and logged correctly, config backup, instead, is logged, but no directory/file/archive is found in the target path.
VMkernel vmhost01.mtka.eu 6.5.0 #1 SMP Release build-17477841 Jan 17 2021 19:24:58 x86_64 x86_64 x86_64 ESXi
In a replica job with "--mail-to=example@example.com", VMs are replicated correctly to target path, but in var/log/xsibackup.log I see an error
SIGTERM (11) condition was trapped: check logs for more details
but no report message is not mailed to example@example.com.
Which logs does xsibackup.log refer to? ESXi's?
Pages: 1