You are not logged in.
If you pass 3072000 GB (3298534883328000 bytes), you are playing russian roulette with the integer limits supported by the system, as some inner calculations use bytes as the base unit. That does not mean that it won't succeed though.
On the other hand, if your VMs are huge you can also hit the /tmp filesystem limit, as some intermediate data is stored on /tmp
--backup-type=custom --backup-vms=REGEXP
If your backup space is a bit more than your VM size, and your VMs are 4 and 8TB, then you are very limited by your factual constraints.
- [b]Onediff[/b]: differential, it just replicates VMs. This is not a backup method alone, as you will replicate any problem in your VM to the mirror VM.
- [b]XSIDiff[/b]: is just a binary OneDiff uses. When used on its own is a good way to move/ copy VMs from one server to another, but not a good backup method for 4 and 8TB VMs, maybe for small ones, depending on your available backup space.
- [b]XSITools[/b]: it's differential and it deduplicates data into its own repositories, which is the folder you will use as the [b]--backup-point[/b]. This is probably your best bet, as it combines deduplication with differential copy.
In your case XSITools is definetely your best option, but you still depend on that additional space, which may not suffice. Combine it with --backup-room=[available space], where [available space] is expressed in GB and see how many backups you can fit in your backup datastore.
The GUI has been designed to speed up first jobs creation. Once you have some basic jobs set up, you will probably find it a lot easier to just duplicate jobs and edit them using vi.
Your script is a good example of how you can extend XSIBackup functionality, but, isn't it a bit of crossing the river to get water?. Don't you think it'd be a lot easier to write a REGEXP with an exclussion group instead of adding an external module.
[b]--backup-vms[/b] argument is exclusive to [b]--backup-type=custom[/b] as explained in the Man Page: [url=https://33hops.com/xsibackup-help-man-page.html](c)XSIBackup Classic Man Page[/url]
The first version of the auto prune feature used MB instead of GB as the size unit. ¿Is there any possibility that you have mixed different versions of the program's constituents?.
You are using [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] as the backup program. Use [b][https://33hops.com/xsibackup-help-man-page.html#prunexsitoolsrepo]--prune-xsitoolsrepo[/url][/b] instead of [b]--del-dirs[/b]. [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] does not generate backup folders as such, those folders only contain the hash-maps of your virtual disks.
[b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] stores backups in deduplicated repositories, you may use [b][https://33hops.com/xsibackup-help-man-page.html#prunexsitoolsrepo]--prune-xsitoolsrepo[/url][/b] to delete individual backups manually, or the [b][https://33hops.com/xsibackup-help-man-page.html#backuproom]--backup-room[/url][/b] argument to let [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] manage the amount of space it uses.
Can you post your command please...
Well, this message is clear:
Error RBAKSRV1: unable to determine the backup point locationThere must be some error in your job syntax, we know nothing about it though.
You don't need an exclude feature when you have REGEXP at your disposal. XSIBackup uses grep -E functionality, which offers extended REGEXP support, including grouping
[url=https://www.digitalocean.com/community/tutorials/using-grep-regular-expressions-to-search-for-text-patterns-in-linux#grouping]Regexp grouping[/url]
And negation
[url=https://stackoverflow.com/questions/10411616/grep-regex-not-containing-string]Regexp negation[/url]
So, practice your regexp in your ESXi command line and then paste it to your job.
You can achieve that in many different ways:
1 - Install NFS services in the Windows server and attach some volume to the ESXi server as a datastore.
2 - Buy some NAS device and install those two disks there. Then you can share the NAS volume both as NFS and SAMBA to be seen by the ESXi host as a datastore and the Windows machines as a CIFS (Samba) share.
3 - Install the Linux subsystem on the Windows server and target it through SSH from XSIBackup.
It just works in the command line. It was the original way to test an SMTP server, forget it, it's not useful any more, it's deprecated and will be removed.
We'll check that
I's easier to put it the other way around, you can use: number, letters, hyphens, underscores and spaces.
The restore module is a script itself, so it's indeed totally scriptable. We'll nevertheless will take this into account and supress the confirmation when used from a script. Nevertheless this is a controverted feature, so we'll add some type of command to remove the prompt for confirmation.
This is only a problem when some circumstances concur: having the need to restore a big number of VMs and using [b](c)XSITools[/b]. When you have some sort of regular backup, restoring is quite easy, as you have an Rsync binary inside the /bin folder.
You didn't say what type of backup you were restoring in any case.
There isn't any difference, both options check the repository
XSIBackup provides the means to handle all this by using the [b][https://33hops.com/xsibackup-help-man-page.html#installcron]--install-cron[/url][/b] and [b][https://33hops.com/xsibackup-help-man-page.html#updatecron]--update-cron[/url][/b] arguments. We really don't know what you have been trying to do or why your cron wouldn't work.
Don't attribute human qualities to the OS, it can't want or like something, there isn't any malevolous spirit hanging around and keeping things from working. You can edit the cron just as long as you leave the file as it was before editing it, same permissions. Of course it's not persistent, that's why XSIBackup uses the --install-cron argument to move the cron logic to the init script.
Add [b]> /dev/null[/b] at the end of the cron line calling the XSIBackup job to redirect stdout to /dev/null and see if this helps.
0 2 * * * "/vmfs/volumes/datastore1/xsi-dir/jobs/001" > /dev/null # Added by XSIBackupThe crontab's default permissions are 1444:
Change them to 0700 to edit it with the root user
chmod 0700 /var/spool/cron/crontabs/rootAnd restore them back to 1444 afterwards, although leaving them as 0700 does not seem to be an issue on our test servers.
chmod 1444 /var/spool/cron/crontabs/rootYou can use the [b][https://33hops.com/xsibackup-help-man-page.html#prunexsitoolsrepo]--prune-xsitoolsrepo[/url][/b] argument to manually prune a repository folder.
Sorry, we had all the information in the backup job, our previous answer is not very precise, just generic.
That is an [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] repository, it's not a regular set of backup folders, but a deduplicated repository.
Timestamped folders do not contain actual data, but the hash maps to rebuild the virtual disks from the chunks stored in the data folder.
The [b]--date-dir[/b] argument is useless in this case, as [b][https://33hops.com/xsitools-vmfs-deduplication.html](c)XSITools[/url][/b] automatically creates one recovery point per backup.
The message in the e-mail report seems clear, it looks like you only have 454G available, but we would need the full output to have access to all details. Take on account that the process will remove the older folders at the end of the backup process. I know it sounds weird, but it's to prevent data loss in case the backup fails. So you will always need some extra room to maneuver, depending on the size of your VMs. Tweak the --backup-room to accomodate the number of backups you can fit.
Automatic deletion will only consider folders that meet the [b]datedirmask[/b] as defined in the conf/xsiopts file
# The following variable holds the directory mask XSIBackup will use when
# deleting older dirs at the time to make room, you do not need to change it
# the pattern below is not a REGEX, but a regular Linux search pattern, it
# checks YYYYMMDDhhmmss strings. Bounds are not checked, just type/length
datedirmask=20[1-3][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]We sent you the software by e-mail.
Best
Yes, sure.
Rsync depends on the cyphers of the SSH tunnel, which in turn create a lot of overhead in the CPU. Both ends of the Rsync protocol must have fast CPUs to handle this rapidly. As this kind of NAS devices rely on "not so fast" CPUs, you end up with a thin stream of data.
In your case, you seem to be using plain Rsync, no SSH tunnel, still your NAS CPU is probably not too powerful and the transfer suffers from that.
You can attach your NAS as a datastore, or if the NAS is in a remote site, you can use (c)XSITools over IP, as it jumps over zeroed zones, which Rsync does not, it will save you a lot of time. On top of that it's differential, so already existing blocks will not be copied over the WAN. But you need full control of the NAS OS, and it needs to be Linux to be able to use (c)XSITools directly.
Yes, XSIBACKUP-PRO license is per crontab, up to 20 hosts from one crontab.
This is regular systems administration of SSH service. Many services work over SSH nowadays and securing this protocol is part of every day system admin's tasks.
You can't block your SSH port, that's the communication protocol between XSIBackup servers.
Use your firewall to limit access based on IP. Changing the default SSH port will keep you safe from most warms that just scan standard ports to break through using delayed brute force attacks mainly.
Configuring the [b]sshd_config[/b] (/etc/ssh/sshd_config) file to disable password authentication will close the main entrance door. XSIBackup uses a key pair to authenticate, which is far more secure.
PasswordAuthentication noIn regards to directly focused attacks (if you suspect you may be the target of one of them). Use a firewall to drop packets comming from unknown networks and use a rate limiting chain to limit the rate of eventual attacks. You can detect the offending networks and even close down the SSH service temporarily if you suspect they may be spoofing some valid IP of yours.
Just add a comma separated list of them