Posts by marco

marco · General matters

Hi,

Thanks for such a comprehensive reply.

Just one point I did miss from my posting; you say

> - You can't backup to iSCSI. We'll reformulate it to: you should not backup to iSCSI.
> Why?: because iSCSI volumes are formatted as VMFS. VMFS is a file system designed to host VMs, namely: a few huge virtual disks, not > millions of small data chunks, which is what an ©XSIBackup repository is. VMFS is excruciatingly slow when compared to XFS or ext4.
>
> This is unimportant when you use the --replica command, as replicating a VM is just copying the virtual disks somewhere else.

Yes, I did at this stage intend to make a 'replica' of the VMs and was not trying to make deduplicated or incremental backups.

However, I understand what you mean.
With the target machine being TrueNAS (running on bare metal), it should be easy for me to remove my iSCSI volume named 'backup', and create simple naitive storage accessible via ssh.

I shall make these changes and retest the speed... it was just odd that -PRO performs very differently from -DC with basically the same source and target.

Thanks again

marco · General matters

I wasn't quite sure what title to give this as I seem to have a couple of issues;

Setup;
Source
a) DL360 G9 running VMWare 6.7
b) DL360 G8 running VMWare 7 (I know this isn't 'supported' by VMWare - but it is a stepping stone in my upgrade process)
Destination
DL360 G8 running TrueNAS
TrueNAS hosts an iSCSI volume named backup... source machines connect to that and mount the datastore 'backup' over iSCSI.
XSIBackup-DC 1.7.0.3, licenced
Switch is Cisco, but only 1GB at present.

Question 1:
On host a) I am seeing a transfer speed of only around 4MB/s when using XSIBackup-DC 1.7.0.3
On the same host, if I run XSIBackup-Pro 11.2.19, I am seeing 82MB/s

My command; ./xsibackup --backup "VMs(RUNNING)" /vmfs/volumes/backup/vmhost0 --compression="no"

I am broadly aware of things that can affect speed - but again this is a test on the SAME hardware - one backup scheduled from the command line as a test, the other the 'normal' cron scheduled one.

Question 2;
I was going to run a comparative test on the second server, but I am running in to the .blocking data issue;

Backup folder '/vmfs/volumes/backup/vmhost1/20230702140010'
-------------------------------------------------------------------------------------------------------------
Obtaining .blocklog data from backup repo...
-------------------------------------------------------------------------------------------------------------
| 2023-07-02T14:00:21 | Error code 4524 at file common.c, line 4524 | Error description: |
| could not find .blocklog_dis file, is_first_backupn.c, line 4524 | Error description: |
| (0) |
-------------------------------------------------------------------------------------------------------------
| 2023-07-02T14:00:21 | Error code 3771 at file xsibackup.c, line 3771 | Error description: |
| something went wrong grabbing .blocklog data

I will look at this in more detail once I have a solution to the speed issue.

marco · General matters

Thanks again for the reply.
I understand now...
So, to have mixed versions of XsiBackup, I will have two directories on my target
\var\data\nfs\backups-with-pro
\var\data\nfs\backups-with-dc

Of course, this is for testing only... I due course I will migrate so that we are using -dc only.

Thanks for the clarification

marco · General matters

Hi,
Thanks for your reply.

I may have used confusing terms in my posting.
I understand that I can't mix -dc and -pro versions when storing backup data to the same place (i.e. the same named directory).
However, what I intended to say, was that I am storing all backups to a Linux machine which has an NFS mount of /var/data/nfs, this nfs directory is then mounted as /vmfs/volumes/backup on the ESXi hosts.

Each backup run is stored in the 'dated' directory from when the backup was run... so in this case under each dated folder there should be no mixed versions.

I do have this apparently working on our local 'test' storage server.

For example, backups stored under /var/data/nfs/20191113001513 made with -dc, and backups stored under /var/data/nfs/20191113021512 made with -pro

I don't want to delete all my historical backups in dated directories before switching to -dc

-dc should 'see' my datastore named 'backup', create a new dated directory, and then write a complete (-dc only) backup to that area?

Maybe I should buy an additional -dc licence and switch all at once?

Thanks for your help so far.

marco · General matters

Hi,

I have another odd issue, I have been successfully running xsibackup-dc on one server for a few weeks now, so decided to try the other licence on another server.

Setup is the same, simplest backup possible, backing up to an NFS share running on an Ubuntu linux machine which is mounted as a datastore 'backup'. So, the VMWare machine 'sees' the target as just another datastore*.

*Note: This target is actually a different machine, though configured the same as the previous tests (one is in our office for testing, the other is located in our datacentre).

Tried mounting as NFS3 and NFS4, both with similar results.
The odd thing being, if I run xsibackup-pro on that host, then it runs fine.

Command line
./xsibackup --backup "VMs(RUNNING)" "/vmfs/volumes/backup" --backup-how=Hot --use-smtp=1 --mail-to=noc@xxxxxxxxxx

Error

(c)XSIBackup-Datacenter setting repository at /vmfs/volumes/backup
-----------------------------------------------------------------------------------------------------------------
2019-11-12T09:31:16 | Error code 2825 at file common.c, line 2825
Error description: the block size of this repository is 0, you can't use a block size of 1048576 to backup to it.
-----------------------------------------------------------------------------------------------------------------
2019-11-12T09:31:16 | Error code 2023 at file xsibackup.c, line 2023
Error description: could not verify/create repository, is target a repository?
-----------------------------------------------------------------------------------------------------------------

Immediately afterwards, I can list the directory, which is present and looks okay (we can see backups made by -Pro)...

ls /vmfs/volumes/backup/
20191108003012 20191109001514 20191109003013 20191110003011 20191111001514 20191112001514 20191112092641 20191112093111
20191108003013 20191109003012 20191110001513 20191110003013 20191111003014 20191112003013 20191112093006

marco · General matters

Just to update the thread...

I have had some good support direct from Roberto.

Backups are now running well, and the rename issue has disappeared when I use the pre-release version 1.006
I understand this may not be related to my issue as the changes in that version should not affect my problem, only the error messages generated.

I am continuing to test and will report back to the forum when the picture is clearer.

marco · General matters

Thanks again for the quick reply.
I am presently running a test backup with the new 1.006 release.
After that completes (or fails), I will retry having set my exports to be 'sync' rather than async. and retry the test.

async might not be working as I had expected.. I thought that it would give me the best throughput, and if at some point it was not 'ready' on a client read or write, it would then block until completion.
The underlying target hardware is an HP server, with a hardware RAID controller with FBWC, it is connected to the source via twin 1GB connections. I suppose it depends what the slowest part of the chain is... I previously thought that async would 'keep up' with the data rate being supplied by the client...maybe with new, faster XSIBackup-dc, I have exceeded that rate at source.

Update later - after trial backup completes.

marco · General matters

Thanks for your quick reply,

Yes, as you say, as far as XSIBackup-dc is concerned, this should be the simplest form of backup, source on a local datastore, backing up to a second datastore on that machine (mounted via NFS rather than direct attached storage).

The target is running Ubuntu 16.04 (reason for an older distribution is that it seems to have better NFS performance than the latest)

My exports file contains;
/var/data/nfs <internal network here>/24(rw,async,no_root_squash)

I am presently mounting this from the ESXi box as NFS4

The odd thing here is that the same host and same target with the same NFS mounted 'backup' datastore works fine with XSIBackup-Pro

Thanks for your help so far.

If you send me a link for the latest .6 release, I can test further (email request sent).

marco · General matters

Hi,
I seem to be having a similar issue to the following post https://33hops.com/forum/viewtopic.php?id=584
I have started a new thread as my configuration is somewhat simpler.

[Don't take it as a 'complaint'... I realise we are early days with XSIBackup-DC... I hope our bug reports can help its development]

Basically I get the above error part way through a backup run... at this point, not only has it part completed a backup of a VM, but it has also fully completed other VMs.
The setup is XSIBackup-DC running on ESXi 6.5 (free version). My backup destination is a Linux machine which is providing an NFS server. ESXi has this NFS volume mounted as a datastore named 'backup'.
I have had this exact same setup using XSIBackup-Pro which works without error.

I have has one backup that completed when I started testing XSIBackup-dc but that was a version zero which I have since upgraded from.

Version: XSIBackup-Datacenter 1.0.0.5

My command line is;
/xsibackup \
> --backup \
> "VMs(RUNNING)" \
> "/vmfs/volumes/backup" \
> --backup-how=Hot \
> --use-smtp=1 \
> --mail-to=noc@xxxxxxxxxxxx

Part of output showing failure:

-----------------------------------------------------------------------------------------------------------------
Virtual Machine Name: FileServer.Black
-----------------------------------------------------------------------------------------------------------------
Creating snapshot VM : FileServer.Black (powered on)
-----------------------------------------------------------------------------------------------------------------
*** Snapshot was successfully created ***
-----------------------------------------------------------------------------------------------------------------
New Backup: FileServer.Black
-----------------------------------------------------------------------------------------------------------------
Backup start date: 2019-10-25 13:34:49
-----------------------------------------------------------------------------------------------------------------
2019-10-25 13:34:49 | Backing up 23 files, total size is 434056647599
-----------------------------------------------------------------------------------------------------------------
NUMBER FILE SIZE PROGRESS
-----------------------------------------------------------------------------------------------------------------
1/23 FileServer.vmsd 443.00 B | Done 0.00%
-----------------------------------------------------------------------------------------------------------------
2/23 temp-flat.vmdk 400.00 GB | Done 0.00%
-----------------------------------------------------------------------------------------------------------------
::: detail ::: 45.59% done | block 18672 out of 40960 | Done 45.11%2019-10-25T16:28:05 | Error code 434 at file dedup-in.c, line 434
Error description: can't rename temp block: /vmfs/volumes/backup/data/e/4/2/b/5/e42b5b14bba8a501bfc14e945103c3a129868c98
-----------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------
SEGFAULT condition was trapped
-----------------------------------------------------------------------------------------------------------------
Cleaning up...
-----------------------------------------------------------------------------------------------------------------
*** Snapshot was removed ***
-----------------------------------------------------------------------------------------------------------------
Removed /tmp/xsi dir OK
-----------------------------------------------------------------------------------------------------------------
Unlocked backup OK
-----------------------------------------------------------------------------------------------------------------
Removed PID OK
-----------------------------------------------------------------------------------------------------------------

Note, that it is nearly half the way through this VM before it errors... it has done nearly 200GB.
It has also completed another VM, total size 64GB before hand.

marco · General matters

NOTE: This may be a similar question to one someone else posted (which I don't think got understood) but that was in the XSIBACKUP-FREE section so I thought I would post my question here.

I am changing my backup configuration so that I can rsync data to a separate Linux machine configured as a nas box.
When I try to create a job to use rsync, the GUI asks me for the remote host details (IP, port and remote path), BUT it appears to assume the access is via 'root'.
In my environment I do not allow direct root access to the server, I log in with another account and then 'sudo su' to get root privileges.

Is it possible to get xsibackup to ask for a username when accessing the linux machine?

What I would like to do is something along the lines of...
--backup-point=backupuser@12.34.56.78:22:/var/data/vmbackups/
but of course that sysntax is not valid

Maybe I am just misunderstanding the process.

What I have at present, which works reasonably well, is my nas servers implement nfs. From the VMWare machines, I mount that nfs volume as a datastore 'backup'.. I then use the vmfs tools to do what it now considers as a local backup to to that second datastore (even though in reality - it isn't local, just locally mounted).

I want to test to see if the rsync method will be faster before I maybe move forwards with other methods.

Thanks

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

#1 Re: General matters » Issues after upgrade » 2023-07-03 19:34:18

#2 General matters » Issues after upgrade » 2023-07-03 07:20:42

#3 Re: General matters » "block size of this repository is 0" » 2019-11-14 09:11:42

#4 Re: General matters » "block size of this repository is 0" » 2019-11-13 08:38:46

#5 General matters » "block size of this repository is 0" » 2019-11-12 11:03:59

#6 Re: General matters » Can't rename temp block » 2019-10-29 11:48:19

#7 Re: General matters » Can't rename temp block » 2019-10-28 11:43:25

#8 Re: General matters » Can't rename temp block » 2019-10-28 10:55:28

#9 General matters » Can't rename temp block » 2019-10-28 09:24:30

#10 General matters » rsync username » 2018-11-29 21:09:12

Board footer