Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Please, read the man page before asking for help:
[url=https://33hops.com/xsibackup-help-man-page.html#backupvmsregexp](c)XSIBackup Regular Expressions[/url]

The name of the installation folder doesn't matter at all, we really don't know what your problem is.
Please express the idea in a concise fashion in your own language, then use Google translator and paste the translation here.

As we stated in some previous response, you "can" use (c)XSIBackup-DC to produce backups that way. Nonetheless that is not the intended usage of the program and rotating doesn't work with custom solutions like this.

Nonetheless, it is extremely easy to delete folders older than some amount of time following a given pattern by using the find command.

UPDATE:

We probably misunderstood you, so here it goes an answer closer to what we believe you were looking for.
If you use something like the Julian date (%j) and calculate its MOD operator [b]$(date %j) % N[/b], you will be creating a rotating pattern which will repeat itself after N iterations (5 in the below example), thus you will copy each VM fully on each initial iteration and just make it differential on the repeating runs.

You can also optionally use the [=cbt] flag to make the replicas be much faster.

This way you keep a set of ready to use restore points.

/scratch/XSI/XSIBackup-DC/xsibackup \
--replica[=cbt] \
"VMs(VM1,VM2, VM3...)" \
/vmfs/volumes/backup/replica/$(( $(date +%j) % 5 )) \
--use-smtp="1" \
--mail-to=mail-from \
>> /scratch/XSI/XSIBackup-DC/var/log/xsibackup.log 2>&1

We aren't really able to get your question.

We distribute two different versions of NAS appliances:

1 - An older one implementing a FUSE real time inline deduplicated File System based on LessFS by [b][url=https://sourceforge.net/projects/lessfs/files/lessfs/]Mark Ruijter[/url][/b] on CentOS 5 that we named [b]XSINAS[/b], which is still a great option for a standalone file server.

2 - A newer one called [b][url=https://sourceforge.net/projects/xsibackup-nas/]XSIBackup-NAS[/url][/b], built on CentOS 7 that incorporates an nCurses GUI, which is a great asset to rapidly deploy a home lab or even production resources in a matter of minutes.

If you already have some dedicated hardware [b][url=https://sourceforge.net/projects/xsibackup-nas/]XSIBackup-NAS[/url][/b] might not be of interest to you, still it is a prebuilt compatible environment that you can start with. It can help you save valuable time and can also serve as an intermediate layer to standarize your deployments.

It also incorporates [b]XSIFS[/b] and offers a way to access files in any XSIBackup-DC restore point in a deduplicated repository.

You can't backup to the very same datastore where your production VMs are.

./xsibackup --backup "VMs(MYVM)" /vmfs/volumes/backup/myrepo --rotate=10

To keep ten restore points.

[url=https://33hops.com/xsibackup-dc-full-manual-home.html](c)XSIBackup-DC full man page[/url]

Thank you for your feedback. It has already been fixed in the manual and the short help (--help argument) will include the fix in the next release.

As said, the most likely explanation is that the virtual disk was already damaged and that you just realized when you tried to perform the backup. (c)ESXi tends to cache as much as possible in memory, thus you can have an apparently working VM sitting on top of some damaged physical or virtual hardware. If that is the case, then only fixing the virtual disk or at least accessing some partition inside is the only way to recover your data. That in turn will depend on the amount and depth of the damage.

As per your comments it is the FS structure inside the guest VM that is damaged. An fsck command may very well fix your issue. The command you posted shows that you may be using LVM2 to partition your disks, if that is the case, you will need to repair the file system on the right logical volume. This guide will help you to understand your layout and fix it.

[url]https://askubuntu.com/questions/1124500/trying-to-repair-lvm-disk-with-fsck[/url]

You normally have three logical layers in an LVM2 layout: PVs, VGs and LVs, namely: physical volumes, volume groups and logical volumes. What you normally format, that is: you draw a file system on are the Logical Volumes.

[img=FluxBB bbcode test]https://www.howtoforge.com/images/lvm/lvm_scheme_full.png[/img]

[url]https://www.howtoforge.com/linux_lvm[/url]

The Device Manager Mapper will usually offer you a good big picture view:

[root@crm ~]# ls -la /dev/mapper/
total 0
drwxr-xr-x  2 root root    100 Jan 26 16:10 .
drwxr-xr-x 18 root root   3480 Jan 26 16:08 ..
crw-rw----  1 root root 10, 58 Jan 26 16:10 control
lrwxrwxrwx  1 root root      7 Jan 26 16:10 vg_pc01-lv_root -> ../dm-0
lrwxrwxrwx  1 root root      7 Jan 26 16:10 vg_pc01-lv_swap -> ../dm-1

The above is a typical default layout on a CentOS system, you will normally want to fsck the root volume.

Performing some SMART diagnostics regularly is critical to prevent this type of situation.

We really don't know what might have happenned with your VM. Nonetheless by per your own comments, we are 100% sure you didn't damage your VM by trying to perform a backup. Not only because [b](c)XSIBackup Free Classic[/b] just reads data, and that is something available for anybody to fact check, as the source code is fully available, but because your VM was running on top of a snapshot, thus: it is impossible that the base disk was directly accessed, not even in read mode.

On top of that, you were performing that backup by means of [b]vmkfstools[/b], which is a binary built into ESXi that I believe nobody knows to have ever damaged a virtual disk.

If you read our first response carefully, we are offering you the clues to recover your VM from the base disks, which as stated above are 100% safe, unless your primary datastore disks/s are broken, which is something we can't obviously know.

How could Onediff possibly make a differential backup when you remove the seed. Worse than that, you are replacing it for something different.

With all our respect: don't do that. Please think about what a differential backup is and how it works before designing your backup strategy.

You don't need to delve into the details of how Onediff works, just imagine some regular differential backup.

Let's say you have performed your first full backup on Sunday and your backup contains: ABCD
Then you perform your first differential backup on monday and E is copied, you then have ABCDE
Then you replace the monday disk by the one from Sunday and copy F, you have ABCDF when you should have ABCDEF

That procedure is not valid.

You don't have any_XSIBAK VM as the above is a first full backup.

2021-02-13T00:25:25|  [WindowsServer] info: should you need to use the mirror VM, register it manually at the backup ESXi host