Posts by herrep

herrep · General matters

This is very strange. When I use XSIBackup-Pro and set the subject line with the --description option, my email server will send the message. When I use XSIBackup-DC from the same ESXI server and set the same subject line, but now with the --subject option, it does not work. How should I debug this scenario?

herrep · General matters

My backup system is a Synology NAS. The backup volume is of RAID type SHR with file system Btrfs. XSIBackup-DC runs on ESXi 6.7, while the backup volume is mounted on ESXi via NFS async mode.

Is there anything I could improve so that I get rid off this sluggish behavior?

In particular, the Synology NAS is the only backup host. Would you rather suggest to run XSIBackup-DC on Synology and have a remote connection to the ESXi to obtain the VM backup data?

herrep · General matters

Could you give some hints as how to switch to sync mode?

Could you briefly explain why the mentioned helper to wait until the folder is created would be misleading? Besides, the folder does not appear to be created at all - at least at my system, cfgbak is simply not there. I only succeed when manually creating the folder and restarting the replica operation again. So I wonder why waiting for the folder to be created would be an option.

herrep · General matters

Hi,

When running XSIBackup-DC with action --backup, I realize that sometimes temporary directories created below ./XSIBackup-DC/tmp remain there, although they have no content in it.

I cannot see any issues with permissions, as the XSIBackup-DC directory and tmp below have both permissions/owners drwxrwx--- root:root and are executed under root.

The last time, I got the following error messages in xsibackup.log:

rm: can't remove '/vmfs/volumes/nas/XSIBackup-DC/tmp/34486014/.vnfs-3d250a-.blocklog': Device or resource busy
rm: can't remove '/vmfs/volumes/nas/XSIBackup-DC/tmp/34486014': Directory not empty
2021-05-15T05:04:17 | Error code 1794 at file common.c, line 1794 | Error description: can't remove directory tree, error: 0

However, when checking the directory /vmfs/volumes/nas/XSIBackup-DC/tmp/34486014 afterwards, I can see that this directory is empty.

Probably worth to note is the following setup:

I run XSIBackup-DC with action --backup and a particular target directory for VMs to be backed up in hot state. During this run, no temp directory was left open. Everything fine. Immediately afterwards I run another XSIBackup-DC with action --backup and the same particular target directory for VMs to be backed up in warm state. During this run, the above errors were shown.

At present, I cannot exactly reconstruct under what conditions tmp directories left open.

Any hints?

Best regards,
Peter

herrep · General matters

Hi,

When using XSIBackup-DC, I would like to create replica from my VMs on a daily basis, only keep the most recent replica (i.e. from today) and to create, for backup purposes, a deduplicated backup repository that is maintained on a daily basis.

As even --backup-how=hot has a small impact, I would like to keep the downtimes of the VMs as short as possible. Therefore, I would like to replicate the VMs first and then run the deduplication from the replicas instead of processing the original VMs again.

Two questions arise from there:

1) Is there any drawback when processing such a chain (original VM => replicated VM => deduplicate replicated VM day by day) instead of working from the original VMs in both cases?

2) Coming from XSIBackup-Pro, --backup-prog=onediff created replicated VMs and registered them with a _XSIBAK postfix in ESXi so that I had no issue to continue with the _XSIBAK VMs for making the deduplicated backup. However, XSIBackup-DC does not appear to provide such a functionality. Do I need to deduplicate source folders where the replica are stored (instead of registered VMs), without the need of registering the replica in ESXi?

Any guidance is highly appreciated.

Best regards,
Peter

herrep · General matters

Hi,

As long as XSIBackup-DC does not detect an error during execution of a backup or replica, a report is generated over the performed tasks and sent via email as specified in the related options. However, I realize that a problem occurring during the backup or replica of one of the VMs results in not sending any email.

For example, when I run xsibackup with option --backup-how=hot and some VMs fail to create a snapshot, then xsibackup will throw an error, but nevertheless continue with the next VM. At the end, after having processed the last VM, surprisingly no report is sent via email. Instead, xsibackup.log shows at the position where the email report should have been sent:

-----------------------------------------------------------------------------------------------------------
2021-05-14T21:22:02 | Error code 162 at file signal.c, line 162 | Error description: raised SIGTERM (11) (2) in job, num of errors: 11, check error.log
-----------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------
SIGTERM (11) condition was trapped: check logs for more details
-----------------------------------------------------------------------------------------------------------
Cleaning up...

---

The error.log shows:

2021-05-14T20:28:31 | Error code 1039 at file esxi.c, line 1039 | Error description: could not create snapshot in <VM-A>, error: KO
2021-05-14T20:28:39 | Error code 1039 at file esxi.c, line 1039 | Error description: could not create snapshot in <VM B>, error: KO
<Listing of all processed VMs>), error count is: 2
2021-05-14T21:22:02 | Error code 162 at file signal.c, line 162 | Error description: raised SIGTERM (11) (2) in job, num of errors: 11, check error.log

Obviously, the snapshot failures do not even result in an immediate termination of xsibackup. Nevertheless, after having coped with a snapshot failure in some of the VMs, no email report is generated.

By the way, I wonder why "num of errors" in the above-shown error.log is 11, although the last error count was 2 which is correct as two VMs could not be snapshotted. 11 appears to be the signal SIGTERM (I assume termination), but why should xsibackup terminate right after having processed all VMs despite of some VMs where the snapshotting failed?

Best regards,
Peter

herrep · General matters

Probably related to [url=https://33hops.com/forum/viewtopic.php?id=944]this issue[/url]?

herrep · © OneDiff

Thank you very much for all these detailed explanations!

herrep · © OneDiff

Thanks a lot for this clarification.

I understood that corrupted differential data will indeed break the backup chain. But if he hash check flags an error and then works again on the next day, I can assume this to be a false negative warning so that everything is all right if the hash check does not flag an error the next day. But if the hash check remains negative, then the backup chain is broken so that the differential backup has to be started from zero again.

herrep · General matters

Hi,

After having configured XSIBackup-DC, I encountered problems in conjunction with the option --config-backup.

When I use the --backup action, the directory cfgbak is properly created prior to writing the config file.
When I use the --replica action, the directory cfgbak is NOT created prior to writing the config file. Therefore, xsibackup aborts with an error.

However, the target directories are on the same disk and have the same permissions. So I wonder what is the reason that the directory can created in one case and not in the other.

Best regards,
Peter

herrep · General matters

Hi,

What I understood from XSIBackup-DC is that the --backup action will result in a repository with deduplicated elements. This confuses me in how far an option like --rotate can be applied. According to my understanding, --rotate assumes a sequential approach of storing differential backup data so that you can simply delete the oldest portions that you do not longer need. But how does this work in a deduplicated scenario?

I would be grateful for an explanation under what conditions --rotate can be used.

Best regards,
Peter

herrep · General matters

Hi,

My mail setup in XSIBackup-DC basically works. I took the existing configuration from XSIBackup-Pro where I had modified the email subject by using the option:

--description="my personal email header"

However, the --description does not appear to change the email subject any longer. I received the status email also from XSIBackup-DC, but without any specific amendment in the subject.

I learned that XSIBackup-DC makes use of the option --subject. Therefore, I added the following option to my script:

--subject="my personal email header"

When I repeat the backup with this option, no email is sent. Instead, I see the following error in the xsibackup.log:

SMTP Error: 550 5.0.0 SUBJECTBLOCK This mail is a virus or spam or a mail loop
-----------------------------------------------------------------------------------------------------------
Errors in SMTP protocol: KO
Returned: No errors in sendmail, next check is protocol

Unfortunately, I do not know as how to further debug this issue. I already changed the subject line in case my text is revoked by the mail server. But the result was the same.

On the other side, email sending works fine via XSIBackup-Pro, from the same server.

Any hints?

Best regards,
Peter

herrep · General matters

Hi,

After setting up XSIBackup-DC to create replicas of VMs, I realized that the --timestamp option does not show any impact. In any case, the replicas are stored directly below the given backup directory so that I assume that the replicas will be overwritten when performing xsibackup another time.

Besides a deduplication backup which I do not discuss here, I would like to maintain a few versions of the replicated VMs. Therefore, I used the following parameters:

--rotate="4" \
--timestamp=`date +%Y%m%d%H%M%S` \

My intention was to store the last four replicas of VMs in dedicated timestamp directories. What needs to be done to reach this goal?

If possible, I would like to keep not exactly the last n versions, but the respective latest version per chosen periodicity, e.g. the 4 latest versions per week.

Best regards,
Peter

herrep · General matters

Hi,

XSIBackup-DC allows to replicate or backup VMs in cold state. Some of the VMs are related in a way to each other that, when one of VMs is powered off, a related VM also needs to remain powered off.

When using the standard procedure in XSIBackup-DC, I can only assure that each VM is powered off one after each other during its own backup. What is the suggested procedure for a VM A and a VM B that both need to be powered off if one or both of them need to be backed up / replicated in cold state?

Best regards,
Peter

herrep · © OneDiff

Hi,

My backup is based on backup-prog=onediff and further a deduplication via backup-prog=xsitools:z.

In rare cases I realize that single VMs report an error after having performed the hash comparison. While this may create some doubts whether the current backup of the VM is indeed usable, I assume that this failure does not have any impact on following onediff backups, as always the entire disks are stored.

Similarly, when trying to restore a backup from the deduplication (xsitools) exactly from the day with the failed hash comparison, it might be questionable if this works, but for any following backups this should not be an issue if there are no hash errors.

Am I right with these assumptions?

Best regards,
Peter

herrep · General matters

Hi,

At present, I am still using a backup configuration based on XSIBackup-Pro 11.2.X and I plan to migrate to XSIBackup-DC latest version.

Now I wonder whether I can reuse all created backup job files and whether the existing backup repositories can be continued just by switching from XSIBackup-Pro 11.2.X to XSIBackup-DC? My regular backup schedule is based on --backup-prog=onediff and --backup-prog=XSITools:z and I would like to simply continue backuping while using the existing repositories created on a daily basis.

Thank you very much for your comments.

Best regards,
Peter

herrep · General matters

Hi,

I have a particular virtual machine which is backed up with xsidiff and xsitools. For this virtual machine, I plan to change the directory name and several file names of the related vmdk harddisk files for consistency reasons, i.e. that the directory name and vmdk harddisk files have the name of the virtual machine. ESXi supports un-registering, changing file names via vmkfstools, editing the vmx file and re-registering the modified virtual machine. This works fine.

Now I wonder what impact such renaming has on earlier backups performed with xsidiff and xsitools. We can assume that the name of the virtual machine remains the same so that xsibackup can easily assign the new file structure to the same virtual machine.

What I would expect is that the renaming does not lead to a malfunction of the backups, but to a one-time increase of backup size after having changed the file names, as the changed files will be interpreted as completely new data, while the old files do not longer exist.

Am I right with this assumption or should I be aware about further side effects that breaks the backup chain once the files have been renamed?

Best regards,
Peter

herrep · © XSITools

Hi,

xsi-backup is set up and works fine. I use a combination of --backup-prog=xsidiff and --backup-prog=xsitools. The location of the backups as specified under --backup-point did not change so far. Now I wonder if there would be any negative impact on the existing backup files when moving the backup root directory to a different location. Clearly, I will set --backup-point to the new directory where I will transfer the existing backup directories. My concern is that the previously stored delta backup files could break if, and only if, the backup path is somewhere stored in the xsitools/xsidiff repository.

I consulted the forum and the man pages, but unfortunately I was not able to identify whether such a change could cause problems or not.

Best regards,
Peter

herrep · General matters

Hi,

I checked conf/xsiopts in the latest version, but I failed to identify any parameter that could be related to amount of repetitions before forcing a shutdown. Will the paramter be added in a later version?

herrep · General matters

I used the VmWare Vsphere ESXi 6.7 WebGUI to create an NFS 4.1 connection to my Synology NAS. At the Synology NAS, I activated "async". I assume that the "async" setting on the NFS server side automatically invokes "async" NFS connections to the clients.

Question 1: Would you rather suggest to use "sync"?

Unfortunately, I did not understand at all the following two sentences:
"You can just add a snapshot to your Onediff image and start your VM after one of these episodes. Then get rid of the snapshot and the Onediff cycle will not be interrupted."

Prerequisite is that my onediff backup showed a certification error which cannot be - according to my understanding - tracked inside a script. So backup finalizes as usual and I realize that there is a certification error. This is my starting point when I should add the recommended snapshot to the (potentially) corrupted onediff image.

Question 2: I do not understand what you mean with "onediff cycle will not be interrupted".

---

Some thoughts on automatic recovery of certification errors:

I got the point that the certification requires a statistical point of view and that we need to avoid endless loops. Because of this statistical approach, I believe that all certification errors which remain below a particular threshold, could be automatically repaired. For example, if a certification fails once, there might only be a read error. Therefore, I would rather expect to repeat the certification again so that another read attempt takes place on the same written data. If this works fine, we are all fine, and there is no need for manual interaction.

However, if the second certificaiton of the same data fails again, I would rather automatically re-execute the backup plus the certification. If this is fine, I would not care much about this one-time issue. However, if the error still persist, manual interaction would be the next step.

In my opinion, some basic treatment of certification errors would be quite helpful, especially as xsibackup right now does not appear to trigger an event in case of an certification error.

herrep · General matters

Thanks for linking the article for further information which I had already consulted prior to writing the post. At present, I backup four virtual machines and the certification errors occured two times within ten days. So I run totally around 40 full backups with onediff, and 2 out of 40 full backups showed the SHA1 error. When I ran the same backup on the next day, everything was fine again.

I understand that the likelihood is rather low that indeed a write error occurred during the backup. On the other side, I rather think that it would be more safe to have an option to repeat at least the certification in case of errors, as I had no problems even 24 hours later. However, I am not sure how to realize this as I needed to detect the certification error on script level and invoke another certification.

Would it be worth to consider an option to handle certification errors and to decide as how to continue?

herrep · General matters

Thank you very much!

herrep · General matters

Hi,

I run a backup job covering a list of virtual machines with option --backup-type=running. Furthermore, backup certification is active with option --certify-backup=yes. I use --backup-prog=onediff so that the resulting backup represents a full backup of each of the virtual machines.

In rare cases, the SHA1 certification fails for one of the virtual machines. In this case, I would like to re-run the backup exactly for that virtual machine where the certification fails. Unfortunately, SHA1 certification failure is not even considered as error, as the backup job added to --on-success is executed.

Is there any way to delete the backup of that virtual machine where the SHA1 certification failed and to re-run the backup for this virtual machine? If not, what is the recommended way to cope with such a situation?

Best regards,
Peter

herrep · General matters

Thank you very much for your hint. I rather increased the amount of 10 seconds loops from 3 repetitions to 9 repetitions. Hwever, I wonder whether an optional parameter could be added so that the modification can be maintained update-proof.

herrep · General matters

Hi,

Is there any way to change the default behavior of powering off a virtual machine for cold backup if the shutdown procedure is not finished within the 30 + 10 + 10 + 10 seconds default period?

I was not able to locate an information as how to modify this default behavior. I only found the following information:

[url=https://33hops.com/xsibackup-help-man-page.html](c)XSIBackup Classic man page[/url]
If you choose "cold" © XSIBackup will issue a shutdown to the virtual machine instance and wait 30 seconds for the virtual machine to be shutdown cleanly. If after the initial 30 seconds period the VM continues to be on the program will wait 30 more seconds checking the VM state every 10 seconds after which © XSIBackup will consider the virtual machine can't be shutdown and it will be powered off.

Unfortunately, the shutdown process of one of my virtual machines takes quite a time, about 90 to 120 seconds. So I wonder whether I can extend the period until xsibackup pro will issue a power off command.

Best regards,
Peter

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

#76 Re: General matters » XSIBackup-DC: SMTP error 550 when using option --subject » 2021-05-16 13:06:52

#77 Re: General matters » XSIBackup-DC: tmp directories not removed after backup » 2021-05-16 12:04:48

#78 Re: General matters » XSI DC 1.4.3.17: job with --replica --config-backup half works » 2021-05-15 10:07:36

#79 General matters » XSIBackup-DC: tmp directories not removed after backup » 2021-05-15 09:30:26

#80 General matters » XSIBackup-DC: run --replica and make --backup from replicated VM » 2021-05-15 01:18:38

#81 General matters » XSIBackup-DC: No email report sent when xsibackup detects an error » 2021-05-14 23:10:21

#82 Re: General matters » XSI DC 1.4.3.17: job with --replica --config-backup half works » 2021-05-14 22:49:48

#83 Re: © OneDiff » Impact on backup chain if sometimes the hash comparison fails » 2021-05-14 22:45:49

#84 Re: © OneDiff » Impact on backup chain if sometimes the hash comparison fails » 2021-05-14 15:07:09

#85 General matters » XSIBackup-DC: dir cfgbak only created with --backup and not --replica » 2021-05-14 13:31:51

#86 General matters » XSIBackup-DC --backup: Use of --rotate in a deduplicated backup repo » 2021-05-14 11:43:08

#87 General matters » XSIBackup-DC: SMTP error 550 when using option --subject » 2021-05-14 11:25:58

#88 General matters » XSIBackup-DC --replica: Keep the latest n versions of replicated VMs » 2021-05-14 10:46:26

#89 General matters » How to keep multiple VMs powered off until cold backup is finished » 2021-05-13 21:48:31

#90 © OneDiff » Impact on backup chain if sometimes the hash comparison fails » 2021-05-13 15:52:29

#91 General matters » Migrate from XSIBackup-Pro to XSIBackup-DC: Continue onediff/xsitools » 2021-05-13 15:33:32

#92 General matters » Impact on xsidiff/xsitools backups after renaming VM files/directories » 2019-11-26 22:16:19

#93 © XSITools » Is moving the backup directory critical when using xsitools or xsidiff » 2019-11-16 15:12:14

#94 Re: General matters » Longer shutdown period than 60 seconds for cold backups » 2019-09-11 22:34:24

#95 Re: General matters » Re-run backup if copy cannot be successfully certified » 2019-08-02 12:25:01

#96 Re: General matters » Re-run backup if copy cannot be successfully certified » 2019-08-02 08:13:13

#97 Re: General matters » Longer shutdown period than 60 seconds for cold backups » 2019-08-02 07:49:05

#98 General matters » Re-run backup if copy cannot be successfully certified » 2019-07-30 22:05:36

#99 Re: General matters » Longer shutdown period than 60 seconds for cold backups » 2019-07-30 21:53:21

#100 General matters » Longer shutdown period than 60 seconds for cold backups » 2019-07-30 06:12:47

Board footer