Posts by michib

michib · General matters

Dear,

When doing backups on a fairly large VM (300GB) I notice these errors raising after 40-45 of daily backups. If I rotate, i.e. empty the repository directory they disappears for others 40-45 days, than back again. Now I have the older backup (they are dailies) at 13-11-2021. When raising these errors VM is backupped but not diffed... i.e. takes a lot longer.

· none: 2022-01-03T11:00:32 | Error code 4179 at file common.c, line 4179 | Error description: .lock on '/vmfs/volumes/backupsvms/PreludeData/data/.blocklog' after 30 s
· none: 2022-01-03T11:00:32 | Error code 3294 at file xsibackup.c, line 3294 | Error description: something went wrong grabbing .blocklog data, error: No such file or directory
· linux-mail-55: 2022-01-03T15:53:06 | Error code 4701 at file xsibackup.c, line 4701 | Error description: some error/s were raised while backing up: VMs(linux-mail-55), error count is: 2

Total blocklog size is actually 200 MB.
Notice that only big VMs are affected (> 300GB); others VM inside the same repository aren't experiencing this behaviour.

Any ideas?

thanks,
regards,
Michele

michib · General matters

Dear,

It's two days that a particular VM backup goes KO with this email log (xsibackup.log is same). XSIbackup-dc is version 1.5.1.1

Detected errors:

· none: 2021-10-27T04:00:32 | Error code 4170 at file common.c, line 4170 | Error description: .lock on '/vmfs/volumes/backupsvms/PreludeData/data/.blocklog' after 30 s
· none: 2021-10-27T04:00:32 | Error code 3289 at file xsibackup.c, line 3289 | Error description: something went wrong grabbing .blocklog data, error: No such file or directory
· linux-mail-55: 2021-10-27T08:10:38 | Error code 4694 at file xsibackup.c, line 4694 | Error description: some error/s were raised while backing up: VMs(linux-mail-55), error count is: 2

Where is the .lock file? Inside data dir? I cannot find it anywhere. I don't have any concurrent jobs from other machines in that timeframe but I know it should be handled by XSI anyway: it locks just for the time needed to read manipulate write blocklog file right?

Question: why it does not stop on error but goes on copying entire VMs files? (in my casa are which are huge 300GB...)

Now I am updating that node to XSI 1.5.1.4 (latest version).
I will postpone that backup job this afternoon to see if I can reproduce.

thanks,
regards,
Michele

michib · General matters

admin wrote:

We sent you a debug version from support. Try it out and let us know if that fixed your issue.

Just to close the thread: as confirmed to your support mail-box, that debug version fixed that issue.

thanks,
regards,
Michele

michib · General matters

admin wrote:

We use Synology as well as many other users and it works OK for us. Nonetheless Synology DSM is a propietary OS. It is based in Linux, still they are trying to make it more propietary every day.
It could be a bug in DSM or a broken disk, you are getting an error on an extremely simple open() system call on a folder that should have permissions. The fact that you can open it up manually just shows that whatever is causing the issue does when running the software interactively.
If we were you we would simply change DSM by some full fledged Linux OS. It could very well be some VM sitting on that same Synology volume.

Thanks for your reply, I know I can put another Linux VM to do that purge/check jobs every day. But... your conclusions on Synology does not persuade me. I'm using DSM 6.2.4. And moreover I know you also use Synology so the question is: do you want to support it or not?

Anyhow I searched inside xsibackup strace output and I do not find any mkdir('/tmp/xsi').... only the rmdir at the end. It's a little strange, isn't it? As far as I know fopen need to have dirs created to make a new file there.

Obviously I can also do a mkdir on my own to fix it as a W/A but... it's not elegant.

thanks,
regards,
Michele

michib · General matters

Hi to all,

When tailing -f on an xsibackup.log file I cannot see it advancing ... I mean no percentage going up... Is there a trick to see it "live"? Something at the TERM level?

thanks,
regards,
Michele

michib · General matters

admin wrote:

That was due to a bug we fixed in earlier 1.5 branch. You can safely delete them if you are using 1.5.1.3. There's nothing more to it than the inconvenience of the place, it was due to a missing root path. Just run
rm -rf /*.map.tmp

I need to upgrade then.

thanks,
regards.
Michele

michib · General matters

Dear,

I created a xsi subfolder inside /tmp just to see, and it went ok.

read(4, "684f40e5cf6aecefddfa;1048576\nfff"..., 4096) = 4096
read(4, "fffe42df0e15b3e35e40c5fea8e5b697"..., 4096) = 4096
read(4, "7d72e0e;1048576\nffff8c52d0c61322"..., 4096) = 1094
read(4, "", 4096)                       = 0
lseek(4, 0, SEEK_SET)                   = 0
close(4)                                = 0
munmap(0x7f784e80f000, 4096)            = 0
access("/volume2/BackupsVMs/PreludeData/.xsitools", F_OK) = 0
open("/volume2/BackupsVMs/PreludeData/.xsitools", O_RDONLY) = 4
open("/tmp/xsi/5341-24324143065589488_edit_tmp", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f784e80f000
fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(5, 0, SEEK_SET)                   = 0
fstat(4, {st_mode=S_IFREG, st_size=64, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f784e80e000
read(4, "Desc: XSITools Repo v 2.0.0\nBsiz"..., 4096) = 64
write(5, "Desc: XSITools Repo v 2.0.0\n", 28) = 28
write(5, "Bsiz: 1048576\n", 14)         = 14
write(5, "Comp: 1\n", 8)                = 8
write(5, "Bcnt: 3881855\n", 14)         = 14
read(4, "", 4096)                       = 0
close(5)                                = 0
munmap(0x7f784e80f000, 4096)            = 0
close(4)                                = 0
munmap(0x7f784e80e000, 4096)            = 0
stat("/tmp/xsi/5341-24324143065589488_edit_tmp", {st_mode=S_IFREG|0644, st_size=64, ...}) = 0
access("/tmp/xsi/5341-24324143065589488_edit_tmp", F_OK) = 0
open("/tmp/xsi/5341-24324143065589488_edit_tmp", O_RDONLY) = 4
open("/volume2/BackupsVMs/PreludeData/.xsitools", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
fstat(4, {st_mode=S_IFREG|0644, st_size=64, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f784e80f000
lseek(4, 0, SEEK_SET)                   = 0
read(4, "Desc: XSITools Repo v 2.0.0\nBsiz"..., 65536) = 64
read(4, "", 61440)                      = 0
fstat(5, {st_mode=S_IFREG, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f784e80e000
lseek(5, 0, SEEK_SET)                   = 0
write(5, "Desc: XSITools Repo v 2.0.0\nBsiz"..., 65536) = 65536
ftruncate(5, 64)                        = 0
close(4)                                = 0
munmap(0x7f784e80f000, 4096)            = 0
close(5)                                = 0
munmap(0x7f784e80e000, 4096)            = 0
unlink("/tmp/xsi/5341-24324143065589488_edit_tmp") = 0
write(1, "\33[90m-\33[0m New block count was s"..., 47- New block count was set to: 3881855
) = 47
stat("/volume2/BackupsVMs/PreludeData/Infrastructure-Mail/20210909070000", {st_mode=S_IFDIR, st_size=26, ...}) = 0
stat("/volume2/BackupsVMs/PreludeData/Infrastructure-Mail/20210909070000", {st_mode=S_IFDIR, st_size=26, ...}) = 0
stat("/volume2/BackupsVMs/PreludeData/Infrastructure-Mail/20210909070000", {st_mode=S_IFDIR, st_size=26, ...}) = 0
open("/volume2/BackupsVMs/PreludeData/Infrastructure-Mail/20210909070000", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4
fstat(4, {st_mode=S_IFDIR, st_size=26, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
getdents(4, /* 3 entries */, 4096)      = 88

Perms on /tmp seems good:

drwxrwxrwt  19 root root  2500 Oct 20 10:03 tmp

After running it rm the /tmp/xsi folder too...

write(1, "The --prune process finished (1)"..., 33The --prune process finished (1)
) = 33
write(1, "\33[90m---------------------------"..., 119-------------------------------------------------------------------------------------------------------------
) = 119
close(3)                                = 0
munmap(0x7f7866aec000, 4096)            = 0
stat("/tmp/xsi", {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
stat("/tmp/xsi", {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
open("/tmp/xsi", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents(3, /* 2 entries */, 4096)      = 48
getdents(3, /* 0 entries */, 4096)      = 0
rmdir("/tmp/xsi")                       = 0

So maybe it is not able to create /tmp/xsi folder? But why since perms ok?

Thanks,
regards,

Michele

michib · General matters

Dear,

Here's the relevant part of strace output. Tell me if you need else.

read(4, "329c45e893d27f69;1048576\nfffb405"..., 4096) = 4096
read(4, "c10f9f63230758890c1b33adef830091"..., 4096) = 4096
read(4, "e3b98a6;1048576\nfffe24a4b1e76c1a"..., 4096) = 4096
read(4, "c0ceb1099a54aed5418552e;1048576\n"..., 4096) = 1502
read(4, "", 4096)                       = 0
lseek(4, 0, SEEK_SET)                   = 0
close(4)                                = 0
munmap(0x7fa523a25000, 4096)            = 0
access("/volume2/BackupsVMs/PreludeData/.xsitools", F_OK) = 0
open("/volume2/BackupsVMs/PreludeData/.xsitools", O_RDONLY) = 4
open("/tmp/xsi/4002-24322042627078724_edit_tmp", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 ENOENT (No such file or directory)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
write(1, "2021-10-20T09:46:55 | Error code"..., 1172021-10-20T09:46:55 | Error code 2833 at file common.c, line 2833 | Error description: can't open fd_tmp_f2edit file
) = 117
write(1, "\33[90m---------------------------"..., 119-------------------------------------------------------------------------------------------------------------
) = 119
open("/var/log/xsi/error.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=2268, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa523a25000
fstat(5, {st_mode=S_IFREG|0644, st_size=2268, ...}) = 0
lseek(5, 2268, SEEK_SET)                = 2268
socket(PF_LOCAL, SOCK_DGRAM, 0)         = 6
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
connect(6, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
sendto(6, "<27>Oct 20 09:46:55 xsibackup: E"..., 143, MSG_NOSIGNAL, NULL, 0) = 143
close(6)                                = 0
write(5, "2021-10-20T09:46:55 | Error code"..., 117) = 117
close(5)                                = 0
munmap(0x7fa523a25000, 4096)            = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
write(1, "2021-10-20T09:46:55 | Error code"..., 1572021-10-20T09:46:55 | Error code 843 at file prune.c, line 843 | Error description: Can't add block count info to: /volume2/BackupsVMs/PreludeData/.xsitools
) = 157
write(1, "\33[90m---------------------------"..., 119-------------------------------------------------------------------------------------------------------------
) = 119
open("/var/log/xsi/error.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=2385, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa523a25000
fstat(5, {st_mode=S_IFREG|0644, st_size=2385, ...}) = 0
lseek(5, 2385, SEEK_SET)                = 2385
socket(PF_LOCAL, SOCK_DGRAM, 0)         = 6
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
connect(6, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2910, ...}) = 0
sendto(6, "<27>Oct 20 09:46:55 xsibackup: E"..., 183, MSG_NOSIGNAL, NULL, 0) = 183
close(6)                                = 0
write(5, "2021-10-20T09:46:55 | Error code"..., 157) = 157
close(5)                                = 0

Seems like it can't open /tmp/xsi/4002-24322042627078724_edit_tmp. Unfortunately no /tmp/xsi directory ...

thanks,
regards,

Michele

michib · General matters

Dear,

Today I discovered in the root of one Esxi system lots of *.map.tmp files named after all the files pertaining to 3 different VMs we're backing on that node.

ls -l /win16*
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50-Snapshot8.vmsn.map.tmp
-rw-r--r--    1 root     root      15534080 Oct 19 08:57 /win16-50-flat.vmdk.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.nvram.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.vmdk.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.vmsd.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.vmsd.tmp.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:00 /win16-50.vmx.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.vmx.tmp.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.vmxf.map.tmp
-rw-r--r--    1 root     root            41 Oct 19 08:57 /win16-50.vmx~.map.tmp

Why are they there?

thanks
regards,

michib · General matters

Dear,

I raised XSIbackup log verbosity to 10:

- 100.00% | removed 4341 from 49665 blocks in folder | 2.26 GB were liberated
- Deleting blocks from .blocklog file...
Allocated blklogarr0 buffer (120746184 bytes)
-------------------------------------------------------------------------------------------------------------
Allocated blklogarr1 buffer (120746184 bytes)
-------------------------------------------------------------------------------------------------------------
blklogarr0 was qsorted
-------------------------------------------------------------------------------------------------------------
Duplicate blocks removed
-------------------------------------------------------------------------------------------------------------
Allocated blklogarr1 uniqued buffer (120746184 bytes)
-------------------------------------------------------------------------------------------------------------
pruneblks (4341) was qsorted
-------------------------------------------------------------------------------------------------------------
- 4341 blocks removed from the .blocklog file
2021-10-09T12:07:56 | Error code 2833 at file common.c, line 2833 | Error description: can't open fd_tmp_f2edit file
-------------------------------------------------------------------------------------------------------------
2021-10-09T12:07:56 | Error code 843 at file prune.c, line 843 | Error description: Can't add block count info to: /volume2/BackupsVMs/Repository/.xsitools
-------------------------------------------------------------------------------------------------------------
- Done deleting blocks from .blocklog file

It seems is raising that error when rewriting blocklog which is on that repository MBs in size...

admin wrote:

The most likely cause is that you run out of space in the /tmp dir.
Extend the /tmp volume.

This NAS has 2G /tmp space ... it seems unlikely it needs to allocate more than 2GB isnt it? Also you state in full manual that: "©XSIBackup-DC uses just RAM to --prune since version 1.4.2.3, you don't need to worry about having enough tmp space. In case you run out of RAM (you will know because an error will be raised stating that fact), just add more RAM to prune the repo or size your repos to the amount of available RAM."

Using a closed down propietary device as your NAS has some serious drawbacks, try to use some full fledged Linux FS when you have some more exigent requirements.
If your set of VMs is of a contained size, default Synology configuration might very well be more than enough. When you start to manage big multi-terabyte repos you need control on the NAS OS, which you don't fully have with closed NAS boxes.

While I understand you point it I must admit this days Synology makes very performant boxes it would be unfair to say you cannot use this boxes to hold multi-terabyte repos. Why don't you support them? Maybe we could also have some specific app as XSI repository backend.

PS: I'm trying to prune backups on my NAS because rotating them on ESXis is a nightmare: segfaults / malloc errors (which are likely to happen due to shell restrictions I think) there. I'll open another thread.

PS2: I'm also a developer. If you could put at level >5 more debug info it could be easier to find out problems... For example loggin perror() on fopen() failing

thanks,

regards,
Michele

michib · General matters

admin wrote:

Just use the installer when upgrading

Dear,

If the customer finds a README that says MANUAL INSTALLATION, maybe the customer is legitimate to think that is up to him to choose whether go for it?

MANUAL INSTALLATION

        Even easier than using the ./install script. Just unzip the main file 
        and then the xsibackup-dc.zip file inside of it, then apply permissions.

        # unzip XSIBackup-DC_*.zip
        # unzip xsibackup-dc.zip        
        # chmod -R 0700 xsibackup* bin gui
        # rm -rf *.zip

        And run: 
        # ./xsibackup-gui

If the only way is using install script, please update your README file accordingly!

It has been a long time since I am using XSIBackup but recently I am a bit disappointed; I think overrall product quality and support quality has suffered a little bit. IMHO XSIBackup-DC is not enterprise production ready, sorry. XSIBackup-Pro was pretty rock solid instead.

thanks, regards,
Michele

michib · General matters

Dear,

While pruning on a Synology Box one backup out of our Repository I get error 2516/2833 at file common.c line 2516/2833. Overral exit code is 0 thou... and exits with success. Happens with versione 1.5.0.x and 1.5.1.1.

V. 1.5.0.x

2021-09-28T15:51:33 | Error code 2516 at file common.c, line 2516 | Error description: can't open fd_tmp_f2edit file

V. 1.5.1.1

2021-09-28T16:18:24 | Error code 2833 at file common.c, line 2833 | Error description: can't open fd_tmp_f2edit file
-------------------------------------------------------------------------------------------------------------
2021-09-28T16:18:24 | Error code 843 at file prune.c, line 843 | Error description: Can't add block count info to:

Full command and log:

bash-4.3# /usr/bin/xsibackup --prune /volume2/BackupsVMs/Repositorya/IM/20210906070000/
|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
|||   (c)XSIBackup-Free 1.5.1.1: Backup & Replication Software                  |||
|||   (c)33HOPS, Sistemas de Informacion y Redes, S.L. | All Rights Reserved    |||
||-------------------------------------------------------------------------------||
|---------------------------------------------------------------------------------|
                   (c)Daniel J. Garcia Fidalgo | info@33hops.com
|---------------------------------------------------------------------------------|
System Information: Linux, Kernel 4 Major 4 Minor 59 Patch 0
-------------------------------------------------------------------------------------------------------------
PID: 30079, Running job as: root
-------------------------------------------------------------------------------------------------------------
- Pruning '/volume2/BackupsVMs/Repository/IM/20210906070000'...
- Ordered and unique blocks: 1892569, Index depth was set to : 6
- 100.00% | removed 16046 from 266367 blocks in folder | 14.10 GB were liberated
- Deleting blocks from .blocklog file...
2021-09-28T16:18:24 | Error code 2833 at file common.c, line 2833 | Error description: can't open fd_tmp_f2edit file
-------------------------------------------------------------------------------------------------------------
2021-09-28T16:18:24 | Error code 843 at file prune.c, line 843 | Error description: Can't add block count info to: /volume2/BackupsVMs/Repository/.xsitools
-------------------------------------------------------------------------------------------------------------
- Removed backup folder: /volume2/BackupsVMs/Repository/IM/20210906070000
The --prune process finished (1)
-------------------------------------------------------------------------------------------------------------
Removed PID                   OK
-------------------------------------------------------------------------------------------------------------

PS: why is it that error number and line number are always the same? Seems weird...

thanks,
best regards,
Michele

michib · General matters

Dear,

admin wrote:

Please use the installer, don't just copy the xsibackup binary, there are new binaries in he package.

I finally had the opportunity to test with installer on one of our production node. Having updated with install solved the problem.
It would be great if you could update also manual procedure cause on production nodes I prefer checking every step performed on datastores.

thanks, regards,
Michele

michib · General matters

Dear,

The full job string was stated in my first post, it's a simple --backup on an NFS datastore. Here's again:

./xsibackup --backup "VMs(testXX)" "/vmfs/volumes/nfsdatastore/Test"

Nothing else strange in command output, only that error I posted.

I've updated by unzipping and lauching

chmod -R 0700 xsibackup* bin gui

to set execution permissions (as found inside README.txt).

Really I'm the only one experiencing this? I have this behaviour on 3 esxi 6.7 nodes (with different patchlevels).

thanks, regards,
Michele

michib · General matters

Dear,

regarding the particular available space issue, unfortunately, it is still there in 1.5.1.1:

2021-09-04T14:08:01 | Error code 1517 at file common.c, line 1517 | Error description: error running command, returned: 127
-------------------------------------------------------------------------------------------------------------
2021-09-04T14:08:01 | Error code 1542 at file common.c, line 1542 | Error description: could not get remote FS available space at /vmfs/volumes/nfsdatastore/Test, details: No such file or directory
-------------------------------------------------------------------------------------------------------------
Available space in backup volume:           -1 (17179.87 PB)

Backup is launched on /vmfs/volumes/nfsdatastore/Test maybe XSIbackup should try to get free space at /vmfs/volumes/nfsdatastore/ instead?

thanks, regards,
Michele

michib · General matters

Dear,

Thanks for you answer, I was OOO so I'm reading it now.

Regarding the creation of repositories in the root of a volume. I was complaining that you changed behaviour of XSIbackup-DC inside a minor revision of the software. Sorry but this is not anyway a good software developing practice. You could have issued a warning saying: "beware the next major version won't allow this...". Then I understand your point but in my particular case using Synology as NAS backend is very easy to export NFS directories so that managing a new arrangement in backups is easy.

Regarding the particular available space issue I will update to 1.5.1.1 and let you know.

thanks,
Michele

michib · General matters

Dear,

I am using DC 1.5.0.14 to backup VMs of a customer from a SSD datastore (SAS) to a "local" NFS datastore exported by a local Synology NAS (RS1221). Esxi is running on an HPE DL360g10 machine. Using 1G ethernet to reach Synology that connects via fiber 10G to a Cisco 550XG switch. Latency is 0.4-1ms.

If I go for a --replica I see results that I would expect: 75-85 MB/s.
If I go for a --backup, even the first shot, on a new repository (empty) I only get 18-24 MB/s. That's a bit disappointing.

I would like to know where could be "the catch".

I found a post in this forum https://33hops.com/forum/viewtopic.php?id=753 where you state that latency is the key factor here.. which I do understand. But I cannot think why there's such a big difference between replica and backup. You state in another post that sha-1 calculation is cpu cheap so not that the guilty. So what? Maybe compression which is enabled by default?

In the same post you state that XSI works differently when going SSH to a NAS because it loads all blocklog db entries instead of checking them one by one. Do you think going SSH instead of NFS will improve in my scenario? [I am a bit reluctantly because as you stated Synology is closing down NAS so early a DSM upgrade could be show stopper] And if so, why not add also an option to enable that in "local datastore mode" ?

thanks,
regards,
M. Baresi

PS: sorry I see that maybe this is a topic for the speed section...

michib · General matters

Dear,

With 1.5.0.14 issuing a simple --backup on an nfsdatastore (no other options given) for a windows 2016 server machine I got erro 1223 could not create snapshot:

2021-08-28T13:42:23 | Error code 1223 at file esxi.c, line 1223 | Error description: could not create snapshot in win16-50, error: Create Snapshot:

As I was issuing manually the command I was worried and checked in snapshot manager but the XSI snapshot is there. Also checked vmware.log but no error there:

2021-08-28T13:42:23.325Z| vcpu-0| I125: SnapshotVMXTakeSnapshotWork: Transition to mode 1.
2021-08-28T13:42:23.325Z| vcpu-0| I125: SnapshotVMXTakeSnapshotComplete: Done with snapshot 'xsi20748739440120514': 1
2021-08-28T13:42:23.325Z| vcpu-0| I125: VigorTransport_ServerSendResponse opID=vim-cmd-48-b38e seq=1087659: Completed Snapshot request.

I am a bit suprised that XSI did not stop and continued with vmdk backup. Is that behaviour expected?

thanks,
regards,

M. Baresi

michib · General matters

Dear,

Version 1.5.0.14 seems to have changed behaviour with respect to datastores. I am using an NFS datastore to backup VMs. With 1.5.0.0 no problem taking a backup inside /vmfs/volumes/nfsdatastore. Now I get error:

./xsibackup --backup "VMs(testXX)" "/vmfs/volumes/nfsdatastore/" 

/!\ It looks like you are trying to backup to the root of an (c)ESXi DS
Please, set some repository at least one level under the datastore

Then if I backup inside a level 1 directory Test I get other errors:

2021-08-27T18:53:30 | Error code 1474 at file common.c, line 1474 | Error description: error running command, returned: 127
-------------------------------------------------------------------------------------------------------------
2021-08-27T18:53:30 | Error code 1499 at file common.c, line 1499 | Error description: could not get remote FS available space at /vmfs/volumes/nfsdatastore/Test, details: No such file or directory
-------------------------------------------------------------------------------------------------------------
Available space in backup volume:           -1 (17179.87 PB)

backup completed ok and created inside datastore under Test all repository stuff.

thanks,
regards,
M. Baresi

michib · General matters

Thanks, I would like to retain the ability to have old versions while not having to buy TBs offsite and contain offsite sync times.

I saw you also give possibility to inspect repository as a filesystem with xsifs. Maybe using rsync with it could it be an option? I'm currently working on a Sinology NAS but I could mount the repo on an external linux for this purpose. How are performances on xsifs?

thanks, regards,

michib · General matters

Hi,

I need to restore every week a certain number of VMs from our XSI backup repository to a dedicated drive where we sync that VMs data to an offsite disaster recovery space. When I restore and the target destination is non empty I see that XSI-DC always zeroes destination files. Is there a way / is supported to modify them differentially instead of creating then form scratch?

thanks,
best regards,

michib · General matters

admin wrote:

Option --timestamp does not exist in (c)XSIBackup-DC
You can produce the same result by using something like the job below.

I'm a bit confused then... Is this outdated? https://33hops.com/xsibackup-dc-full-ma … #timestamp

regards,

michib · General matters

admin wrote:

We really didn't get you on this:
I indeed tried running replica with --timestamp without datetime parameter but it complains (only raising verbosity..) about the missing datetime. Just fixing this could be really appreciated.

As I was saying in my previous post I was trying to replicate xsibackup-pro behaviour: i.e. creating timestamped dirs with exact VM replicas ready to run.

So at first I launched with option --timestamp without any = date part 'cause I read in the manual that xsibackup-dc would have put it to 'now' at runtime. I also used --rotate=3. No timestamped dir was created and no error was raised if my memory is not wrong. Simply I had a directory named after the VM name. Then I put --verbosity=5 and it logged something like 'timestamp is missing parameter'...

Don't know if I answered your 'question'.

regards,
Michele

michib · General matters

admin wrote:

We will dedicate some development time to this in the following days. We are finishing to test new features that will allow you to rotate multiple replicas, as some users prefer to keep ready to use copies even though it may take more time to complete the backups. Nonetheless since we added the multitenant CBT feature, this technique has emerged as some much more feasible way to keep ready to use copies, just as long as you have the necessary space to host them.

Hi,

I'd like to support this. We also would appreciate to have the ability to make xsibackup-DC work in replica mode in a similar manner to the xsibackup-pro we're still using on other nodes. I understand this is not the way DC was enginnered but it could help to start using it while migrating disaster recovery tools & batches on our NAS that were written to work on replica timestamped dirs.

I indeed tried running replica with --timestamp without datetime parameter but it complains (only raising verbosity..) about the missing datetime. Just fixing this could be really appreciated.

regards,
Michele

michib · © XSITools

admin wrote:

Then you can say that device is not working as expected. Read errors are probably more common on rotational devices (I really don't have any figures on mind now), but when you get some checksum right out of 5, you can say that device is broken without any further comparison.
It might be just a bad cable, some bad disk or something that can be easily fixed, but so many errors indicate a failing device. Keep an eye on the inner cables if any, sometimes you are in a hurry and you just plug whatever you can find in. If some cable is below the spec, things will still work, but you would experience things like that.

Dear,

I checked pretty much all "the line" and nothing was there. So I got back this time checking XSI logs also... I noticed a strange thing: sha1 fails on the smallest vmdk, 16GB, and never on the second which holds mail data and is definitely bigger >150GB. So I checked 3 months of e-mail reports and it never failed on the bigger one: it seems very strange to me.... Also the mail sent says in subject 'No errors detected in backup jobs' but then body says:

 "Last error raised for the above VM:
ERROR CLNCERT0, details: [linux-mail-55] error: sha1 hashes are different [linux-mail-55-flat.vmdk], details: 0".

What Last error means? Any ideas? I have actually brought an update for XSI but didnt update on production: do you think it could help solving this?

thanks,
regards.

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

#1 General matters » XSIBackupDC 1.5.1.4 Error code 3294 e 4179 » 2022-01-04 15:59:50

#2 General matters » Error: .lock on repository/data/.blocklog' after 30s » 2021-10-28 08:49:09

#3 Re: General matters » XSIbackup-DC 1.5.1.1 - error 2516/2833 while pruning on a Synology Box » 2021-10-28 08:40:47

#4 Re: General matters » XSIbackup-DC 1.5.1.1 - error 2516/2833 while pruning on a Synology Box » 2021-10-20 09:05:30

#5 General matters » There's a trick to tail xsibackup.log while xsi is running? » 2021-10-20 08:24:38

#6 Re: General matters » *.map.tmp files found in / of ESXi filesystems? Why? » 2021-10-20 08:15:20

#7 Re: General matters » XSIbackup-DC 1.5.1.1 - error 2516/2833 while pruning on a Synology Box » 2021-10-20 08:06:27

#8 Re: General matters » XSIbackup-DC 1.5.1.1 - error 2516/2833 while pruning on a Synology Box » 2021-10-20 07:53:04

#9 General matters » *.map.tmp files found in / of ESXi filesystems? Why? » 2021-10-20 07:29:04

#10 Re: General matters » XSIbackup-DC 1.5.1.1 - error 2516/2833 while pruning on a Synology Box » 2021-10-09 10:19:39

#11 Re: General matters » XSIbackup-DC 1.5.0.14: cannot backup at datastore root » 2021-09-30 08:08:58

#12 General matters » XSIbackup-DC 1.5.1.1 - error 2516/2833 while pruning on a Synology Box » 2021-09-28 14:09:42

#13 Re: General matters » XSIbackup-DC 1.5.0.14: cannot backup at datastore root » 2021-09-28 13:59:59

#14 Re: General matters » XSIbackup-DC 1.5.0.14: cannot backup at datastore root » 2021-09-09 12:32:00

#15 Re: General matters » XSIbackup-DC 1.5.0.14: cannot backup at datastore root » 2021-09-04 14:06:16

#16 Re: General matters » XSIbackup-DC 1.5.0.14: cannot backup at datastore root » 2021-09-04 09:40:47

#17 General matters » XSIbackup-DC 1.5.0.14: questions on performance » 2021-08-28 14:13:36

#18 General matters » XSIbackup-DC 1.5.0.14: error code 1223 but backup goes on? » 2021-08-28 14:00:40

#19 General matters » XSIbackup-DC 1.5.0.14: cannot backup at datastore root » 2021-08-28 13:55:22

#20 Re: General matters » XSIBackup-DC: Is restoring differentially supported? » 2021-07-30 14:25:20

#21 General matters » XSIBackup-DC: Is restoring differentially supported? » 2021-07-30 09:53:03

#22 Re: General matters » Replica XSIBackup-DC versions » 2021-07-14 15:13:39

#23 Re: General matters » Replica XSIBackup-DC versions » 2021-07-13 19:59:29

#24 Re: General matters » Replica XSIBackup-DC versions » 2021-07-13 10:59:20

#25 Re: © XSITools » IP Backup to Synology - error: SHA1 chunk hashes check failed » 2020-02-12 09:18:46

Board footer