Is there any drawback when scheduling regular backups on a virtual machine via xsitools and also, probably in a less frequent interval, scheduling backups on the same virtual machine via onediff or xsidiff?
I assume that the snapshot mechanism used by onediff does only interfer with xsitools to the extent that the snapshot file will be stored in a xsitools date directory for each single differential backup instead of being deduplicated in the data directory. However, due to the short time interval between creating the snapshot and processing the xsitools based directory, the snapshot will be very small.
Furthermore, I do not assume that xsidiff somehow negatively interfers with xsitools.
Or would it be recommendable to chain the backups, i.e. perform onediff first and then process xsitools on the onediff copy of the virtual machine? The approach described in this post looks promising:
Up to now, I refrained from doing so because of backuping up to a Synology NAS which suffers from gaining full root access. I was a bit scared about executing xsibackup directly on the Synology NAS because of issues around the root access, please see post:
Therefore, I made the Synology NAS locally available to the ESXi server via NFS and avoided executing xsibackup with xsitools in a chained setup.
However, the Synology NAS has enough memory so that I could run a VM in which I have full root access and where I can access the disks of the Synology NAS. This leads to my question: Are there very good reasons to perform xsitools directly on the Synology NAS once the onediff copy has been transferred to the Synology NAS?
Furthermore, I am not sure whether the NFS connection is the best choice. Would it be more recommendable to use an ssh connection to my Synology NAS like the xsibackup manual suggests when connecting to another ESXi Server (which the Synology NAS not is):
B) Full path in a remote ESXi host by using the following syntax: --backup-point="IP.OF.REMOTE.SERVER:PORT:/full/path/todatastore"
Last edited by herrep (2019-07-13 12:39:12)
You pointed out one of the keystones of chained backups. XSIBackup real power starts to unleash when you take advantage of the many different ways it can be used.
The two key facts to keep in mind are:
- Onediff will use a management snapshot to keep differential data. It will just be kept there in between backup cycles.
- All other backup methods will respect any pre-existing snapshots, they will take their own and backup whatever is there at the time to perform the backup. So the Onediff snapshot will still be there at the time the subsequent Onediff cycle takes place. In other words, you can do whatever in between Onediff cycles, just as long as you don't delete the delta snapshot.
From the two main facts above you can derive your conclusion: yes, you will be backing up the delta snapshot when you perform an XSITools backup and thus you will be keeping it as is. Deduplication will not affect the Onediff delta snapshots, so you will be worsening your compression ratio. Nonetheless, there's one advantage to it, as you will be keeping two restore points per XSITools backup, as you can use the snapshot or discard it.
(c)XSIBackup Datacenter is our next generation solution, it employs the same general principles as XSIBackup-Pro, but it's much simpler to use and it deduplicates everything, including small files.
Synology and QNap are both excelent NAS devices manufacturers, but you cannot use their OSs as if they were a regular Linux distros. Root access is limited, even for some basic administration tasks, thus if you try to use them as an OS you will most of the times end up banging your head agains the wall.
You can easily gain access to any storage volume by just using a bridge Linux VM. Attach whatever volume you want to this Linux VM and backup to it over IP. You can attach disks via NFS, iSCSI, SSHFS, etc..., you just need the connected volumes to be available over SSH.
If you try to reach the Synology over SSH you will be hitting the fact that you don't have full root access, you will have to configure additional users and eventually fall into a permissions nightmare. Our recommendation is that you use the synology as an iSCSI or NFS volume and mount those volumes directly to the ESXi server or to some bridge Linux box.