Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Run adding --debug-print to see why that command is failing.

In the ©XSIBackup-App appliance we are using [url=https://www.rapid7.com/products/insightvm/download/thank-you/?utm_medium=email&utm_source=email&CS=email]Swaks[/url] as an SMTP client by now, which requires authentication.

This will change in next version 1.1.0.1, the new default SMTP client will be cURL in sake of compatibility and to limit space usage, as Swaks depends on Perl and in the end requires more than 45 MB for just an e-mail client.

©XSIBackup-App 1.1.0.1 will also allow to select the classic ©XSIBackup sendmail module, which has been ported to Linux, via the --smtp-client=sendmail argument. Sendmail module uses STARTTLS (port 587) while cURL method (default) uses a direct TLS/SSL connection on port 465.

All these changes are transparent to the user 99% of the times, except in cases like yours in which you are using an open relay and Swaks does not support that configuration.

You have posed your question in the [b]©XSIBackup Classic Free[/b] forum. Is this the version you are using?.
Please clarify to move your question to the right forum if needed.

You seem to simply not have formatted the partition you are trying to mount.
[url]https://unix.stackexchange.com/questions/315063/mount-wrong-fs-type-bad-option-bad-superblock[/url]

Thank you for your feedback. There is something going on there. From time to time some user tells us about something similar.

The thing is that a correct shut down or snapshot with proper service management should yield a fully working system. If you get a BSOD and you do know that the BSOD is related to AD, then there is only one possible cause: [b]the AD service wasn't properly shut down[/b]. Your BSOD is clearly stating that point with the [b]0xc00002e2[/b] error (this error is an indication that the Active Directory database NTDS.DIT is corrupt).

Thus, the solution is conceptually simple, yet, the usual MS fuzz around simple issues seems to reach it's peak around this problem, which has been around for decades. Virtualizing Windows Server only makes the problem worse, but this already happenned in hardware based servers 20 years ago. The simple solution to this is: [b]how the H. to shut the AD service down in a controlled way[/b].

It is rather obvious that a normal Windows shut down should yield a working system, thus using the --backup-how=cold argument has to work. There is only one thing to take on account in that case and it is to make sure that ©XSIBackup was indeed able to perform a controlled shut down and not a power off instead. Increase the timeout in xsibackup.conf to make sure this is indeed what's happening. The event viewer in the Windows OS should make it clear whether the previous shutdown was performed correctly or it was a mere power off.

--backup-how=cold does shut the server down and then backs up the VM from a stopped state, this must yield a fully working system 100% of the times, just as long as the shut down was indeed controlled. Please do make sure that your VM is not being powered off instead, we are sure this is the only possibility in case you are still getting the BSOD after a cold backup or replica.

UPDATE:

The command

net stop NTDS /y

Should produce a controlled shutdown of the AD services. If you are getting a BSOD after running it, then your AD service is not working right, you may need some additional patch for your OS or some additional service installed.

We would start by issuing [b]net stop NTDS /y[/b] manually, then reboot. Also trying [b]net stop NTDS /y[/b] followed by [b]net start NTDS[/b] and making sure that AD is still working right would help determine whether the issue is with the AD service itself or with the VMWare Reboot process.

Also make sure that all services related to snapshots are present in the way described in our [url=https://33hops.com/troubleshooting-windows-snapshots-in-esxi.html]post on Windows snapshots[/url]:

Volume Shadow Copy
Microsoft Software Shadow Copy Provider
VMware Snapshot Provider
COM+ System Application
COM+ Event System
Virtual Disk

Things such as having Secure Boot features enabled in your BIOS can also contribute to create these type of issues.

As a workaround we suggest that you backup the C:\windows\ntds\ntds.dit file from a known working state to be able to easily restore it in case of need.

Thanks for the link. We published a post with a more [b][url=https://33hops.com/esxi-snapshot-errors-and-solutions.html]comprehensive approach to freeze scripts[/url][/b] some time ago.

It's somewhat awkward that MS has not published detail information on how to stop AD services in a controlled manner. There is very little information on the subject. Nonetheless AD is a complex service dependent on a database where it stores its configuration. The principles that apply are the same as with any other system dependent on a consistent I/O scheme.

Just as long as you are able to stop it in a controlled way you got it. Controlled freezing (stop service before taking the snapshot and restart after the snapshot was done) is even better, as you don't need to stop the VM.

Sorry for reaching back so late, your last response passed inadvertent to us.

AD machines are picky to quiesce, probably pickier than they should be. The AD database should be more resilient to blackouts and simple power offs, anyway...

Both warm and cold --backup-how methods should work with any system. The reason is simple: a "controlled shutdown" (we'll get back to this in the next paragrah) precedes the snapshot, thus the snapshot is taken from a stopped state of the VM. That stopped state of the VM should yield a perfectly coherent state of the VM as the shutdown process must take care to bring down all services in a controlled maner including AD services. This controlled shut down should take care to flush all pending data to disk and make sure that the AD DB is in a perfectly coherent state, just as if you were switching off any hardware based server.

Now the thing is whether the shutdown was really a controlled shutdown. ©XSIBackup tries to perform a normal controlled shutdown and if it can't it issues a power off. You can find a tweakable variable in the [b]etc/xsibackup.conf[/b] file to control the time ©XSIBackup waits before issuing a plain power off.

If your server is busy and it takes longer than the default configured time ©XSIBackup may be powering off your AD server instead of shutting it down gracefully causing the AD database to become corrupt. Check that in the backup log and extend the default timeout if you need to.

You can also use a freeze script via VMWare Tools (see previous post above) to switch AD services off before the snapshot is taken, this would allow you to backup the VM while it is on.

The key is to make sure the AD related services are brought down in a controlled manner to avoid corrupting the AD database.

(c)XSIBackup IS NOT compatible with vSAN.
Any attempt to backup VMs in a vSAN volume will yield undefined results.

If you have missing blocks you can't create them out of thin air. You should check your repos from time to time to prevent this kind of thing from happening. We can't assess what is the reason for the block loss, it could be from a damaged disk to incomplete backups that returned some errors or a partially deleted repository.

First of all you should use some newer version to restore. Restore functionality is not limited by any license check, thus you can use the free version to restore.

If you use the --force argument at the end of your restore command you will be able to restore your disk without the missing blocks, just holes instead of those blocks.

If you keep getting a segfault, then the repo could be broken. The reason for that could be missing or damaged files or them having been edited with some text editor that changed the line ends or the file encoding.

You should check that you have an .xsitools file in the root of the repo that you can read with cat or vi, a data folder with a block manifest named .blocklog and the backup folders in the repo root with .map files that contain the constituent blocks.

.xsitools file

Desc: XSITools Repo v 2.0.0
Bsiz: 1048576
Comp: 1

The data folder contains a hierachical structure with the block data in a six level nested folder set.

[root@localhost ~]# ls -la /home/backup/repositories/repo01/data/
total 360
drwxr-xr-x. 18 root root    167 Aug 15 22:51 .
drwxr-xr-x.  8 root root    145 Aug 15 22:51 ..
drwxr-x---. 18 root root    150 Aug 15 18:51 0
drwxr-x---. 18 root root    150 Aug 15 18:52 1
drwxr-x---. 18 root root    150 Aug 15 18:51 2
drwxr-x---. 18 root root    150 Aug 15 18:51 3
drwxr-x---. 18 root root    150 Aug 15 18:51 4
drwxr-x---. 18 root root    150 Aug 15 18:51 5
drwxr-x---. 18 root root    150 Aug 15 18:51 6
drwxr-x---. 18 root root    150 Aug 15 18:51 7
drwxr-x---. 18 root root    150 Aug 15 18:51 8
drwxr-x---. 18 root root    150 Aug 15 18:52 9
drwxr-x---. 18 root root    150 Aug 15 18:52 a
drwxr-x---. 18 root root    150 Aug 15 18:52 b
-rw-r--r--.  1 root root 366121 Aug 15 22:51 .blocklog
drwxr-x---. 18 root root    150 Aug 15 18:52 c
drwxr-x---. 18 root root    150 Aug 15 18:51 d
drwxr-x---. 18 root root    150 Aug 15 18:51 e
drwxr-x---. 18 root root    150 Aug 15 18:52 f

Some repo restore point folder:

[root@localhost ~]# ls -la /home/backup/repositories/repo01/20230815227220/WXPMK
total 1048
drwxr-xr-x. 2 root root    4096 Aug 15 22:51 .
drwxr-xr-x. 3 root root      19 Aug 15 22:51 ..
-rw-r--r--. 1 root root      97 Aug 15 22:51 vmware-10.log.map
-rw-r--r--. 1 root root      97 Aug 15 22:51 vmware-11.log.map
-rw-r--r--. 1 root root     146 Aug 15 22:51 vmware-12.log.map
-rw-r--r--. 1 root root      48 Aug 15 22:51 vmware-13.log.map
-rw-r--r--. 1 root root      97 Aug 15 22:51 vmware-14.log.map
-rw-r--r--. 1 root root      48 Aug 15 22:51 vmware-15.log.map
-rw-r--r--. 1 root root      48 Aug 15 22:51 vmware.log.map
-rw-r--r--. 1 root root 1003520 Aug 15 22:51 WXPMK-flat.vmdk.map
-rw-r--r--. 1 root root     118 Aug 15 22:51 WXPMK.info
-rw-r--r--. 1 root root      45 Aug 15 22:51 WXPMK.info.map
-rw-r--r--. 1 root root      46 Aug 15 22:51 WXPMK.nvram.map
-rw-r--r--. 1 root root      45 Aug 15 22:51 WXPMK.vmdk.map
-rw-r--r--. 1 root root      44 Aug 15 22:51 WXPMK.vmsd.map
-rw-r--r--. 1 root root      44 Aug 15 22:51 WXPMK.vmsd.tmp.map
-rw-r--r--. 1 root root      46 Aug 15 22:51 WXPMK.vmx.map
-rw-r--r--. 1 root root      46 Aug 15 22:51 WXPMK.vmx~.map
-rw-r--r--. 1 root root      46 Aug 15 22:51 WXPMK.vmx.tmp.map

Detail of some .map file

[root@localhost ~]# tail -n20 /home/backup/repositories/repo01/20230815227220/WXPMK/WXPMK-flat.vmdk.map
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
6bf4834b3c2b6d46e03886a99b31e75b5dc6df00;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576
3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3;1048576

The end of this -flat.vmdk file contains mostly 1MB zeroed blocks (3b71f43ff30f4b15b5cd85dd9e95ebc7e84eb5a3), thence the hash repetition.

(c)XSIBackup-App detects duplicate disks and prepends the datastore name to the disk file when using --backup action. This feature will be available to (c)XSIBackup-DC in next version.

You should name disks uniquely within one VM though. (c)XSIBackup consolidates all disks in one folder in order to produce a working VM when restoring. It does its best at the time to rearrange disks in a new working .vmx file, still that is just a recomposition of the original set up. We can't assume that (c)XSIBackup will find the exact same infrastructure when restoring, as this would be counterproductive in most DR situations, thus we always aim at producing something that will work from a single directory.

When you restore such a VM you will end up having to rearrange things according to the original layout or to a totally new reality. Naming disks uniquely will guarantee that the restored VM will work out of the box without having to eventually edit the .vmx file.

You should rename disks manually to be 100% sure on what is the final result as the VSphere GUI is just an abstraction layer and doesn't always do what you would expect.
Renaming a disk is rather simple:

1/ Stop the VM.
2/ Change the -flat.vmdk file name.
3/ Edit the .vmdk file descriptor to point to the new -flat.vmdk file and remove any CBT related lines. The [b]# Change Tracking File[/b] section.

# Change Tracking File
changeTrackPath="VM01-ctk.vmdk"

4/ Edit the .vmx file to point to the new .vmdk file descriptor and delete any CBT related lines, usually at the end of the file if enabled through --enable-cbt argument.

ctkEnabled = "TRUE"
scsi0:0.ctkEnabled = "TRUE"
scsi0:1.ctkEnabled = "TRUE"
scsi0:2.ctkEnabled = "TRUE"

5/ Reboot the VM and eventually run --enable-cbt again.

UPDATE:

There is already a version available (1.7.0.7) which addresses duplicate named disks by prepending the datastore name to them. Please note that when you restore the VM you will have to edit the .vmx file after deciding where to put those disks.

TrueNAS is a closed down environment built on top of FreeBSD, which is not Linux. (c)XSIBackup has been designed to work with Linux OSs. There isn't a server component for FreeBSD and even if there was you would still be limited by a closed down OS designed to work as a user program.

Thanks to being an extremely flexible tool, you could even achieve backing up to USB key attached to a Smart TV over Wi-Fi, if that was your only goal. Nonetheless, in creating exotic configurations you will loose speed, reliability and even some features such as the possibility to do granular restores.

Devices such as TrueNAS are OK for novices or to have at home, they won't be close in possibilities to using a full fledged Linux OS though.

On the other side, adding a disk, formatting it and connecting to a Rocky Linux 8 minimal install is even easier than setting up a device such as TrueNAS.

1/ OpenSSH comes configured by default and with port 22 open in the firewall, so you have to do nothing.
2/ If you install to a big disk you won't even have to configure it, you can directly run --add-key against the Linux backup host IP and start using.
3/ In case you want to add additional disks you can just run a one liner to have it partitioned and formatted as XFS.