Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

[quote=admin]Yes, most of the overhead in Rsync transfers is caused by the SSH encryption and/or compression. What kind of server/CPU are you using?[/quote]

Ok, but when the transfer speed is normal the cpu is about 40-50%.

Manufacturer:     Dell Inc.
Model:     PowerEdge R720xd
Processors:     8 CPU x 1,999 GHz
Processor Type:     Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
Hyperthreading:     Active
Total Memory:     95,96 GB

[quote=ulfthomas]

Long story short:

•    I converted the disk to GPT (I can revive the link if needed)

...
[/quote]

I'm interested at the link, can you provide it?

If i understood the xsitools logic, deleting a dir could create orphaned blocks, check this "ugly version" script to check if the are orphaned blocks.

It must be copied into xsitools repo main  folder, and forgive the "2017*" filter used on grep, i'm not a skilled bash developer, suggestions are welcome!

#!/bin/sh
#
# Check orphaned blocks in xsitools repository
#
# ugly first version
#
# gets total existing blocks
brecrd=$( cat .xsitools | grep Bcnt | awk -F ': ' '{print $2}' )
echo $(date) Total blocks: $brecrd

bproc="0"
#for each block search if referenced in any vmdk flat file ...
find ./data -type f -exec basename {} \; | while read  file
do
#ugly filter to exclude .data folder   
  ret=$(grep -lrx -m1 $file 2017* | grep ".vmdk" | wc -l)
# progress counter      
  bproc=$(( $bproc + 1 ))
  n=$(($bproc%100))

  if [ "$n" == "0" ]
  then
    echo $(date) Processed: $bproc of $brecrd  
  fi 

# if found print it, for now, todo: delete it
  if [ "$ret" == "0" ]
  then
    echo Found unused block: $file  
  fi 
done;

[quote=admin]We are starting to mix different issues into this topic.
We had previously detected an issue with dd not being able to access a .vmdk file when checking its first 50M (Jayce pointed this out). This is most probably due to some other process holding it. We have not been able to reproduce this issue so far, and might not be a bug.

Getting a [b]Segmentation fault[/b] or [b]file too large[/b] from part of [b]dd[/b] are traces of a different sort of problem.

dd uses C file handling functions, these functions generally use a type [b]off_t[/b] to seek inside files. That error (file too large) means you have hit the limit of a data type. It could be due to your file being extremely big, or to a bug in the dd binary of your ESXi build.

We are willing to help you, but although we have insisted in getting some more details about this issue, we have nothing but comments.

If this topic has to be considered related to a real problem, please provide:

- Backup job string with all arguments (except passwords)
- ESXi version and build number.
- Logs containing the exact errors you are getting[/quote]

Well, I was busy too, but during this time I set up a new ESXI host (6.0.0) redirecting all remote backups to this host, with internal hdd storage. The one that is having problems has a NAS (QNAP TS-420) attached in the local network.

This was about one week ago, and until yesterday there were no errors.

So the problem has moved to the NFS datastore created linking the NAS RAID volume, don't know if could be the NAS hardware, firmware, or something else, but i thing nothing related to XSIBackup itself.

Hope this helps investigating.

why not use the provided function in xsibackup?

save a copy of the xsibackup, if any
run xsibackup --inst-cron

edit the file xsibackup-cron and add your backup jobs

lot of useful articles in blog [url]https://33hops.com/blog-main.asp[/url] and man page [url=https://33hops.com/xsibackup-help-man-page.html](c)XSIBackup Classic Man Page[/url]

thanks, solved adding a new disk, and then removing it, from the vSphere client, the ghost disk disappeared.

[quote=admin]Run this and note the output

cat /vmfs/volumes/datastore1/BKPMAN/BKPMAN.vmx | grep ".vmdk"

XSIBackup just collects the information present in the configuration files[/quote]

scsi0:1.fileName = "/vmfs/volumes/52af331b-f40ac352-efea-5cf3fcb0ddc1/temp/WinServer2012_01_1.vmdk"

You are right, wow, seems a ghost disk, not appearing in VM settings, do you think i can safely remove that line?

Also i noticed another strange behaviour, if launch a remote backup job (other host, datastore on NAS in the internal lan, other than the datastore of the VM) using onediff, the VM *_XSIBAK are not created, is it normal? If i launch the job within then host they are created.

During xsidiff testing i tried to backup a VM in "hostB" located on public hosting provider with 100Mbit internet bandwidth, launching the backup from "hostA" located in my office. The first try (or second i'm not sure) raise the 50M error, repeating the test (to verify the speed of xsidiff backup) the error didn't happen, with the backup successfully executed in a few minutes. Hope helps debugging...