Forum ©XSIBackup: ©VMWare ©ESXi Backup Software
MenuYou are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: General matters » Viewing running backup processes, status and progress » 2019-10-19 02:05:33
If you got disconnected from your SSH session while the process was writing to STDOUT in a TTY then you most probably have a zombie process, as closing the SSH tunnel will not allow the program to run in the background ....
So, redirect your processes output to a file when run from the cron, it's default behaviour. You can inspect what's going on by using tail -f xsibackup.log. Kill any eventually hanged process resulting from any SSH broken session by looking for the process
ps -c | grep xsiAnd kill it.
kill -9 PIDAnd when you run a command through a remote session, use nohup + & while redirecting to the log, or assume that in case your SSH session ends abruptly, your process will just go to "purgatory".
You know what I thought that about the SSH session would end the processes, but to my surprise xsibackup reported it as still running. I did run the PS and grep for xsi but I got no processes back as running so I just assumed there were some other subprocess at work. Why would the xsibackup report the process as still running?
And just a suggestion, maybe it would be nice if the xsibackup executable would give a little more detail when it detects another process running. Maybe provide a PID and heck, while it's at it, might as well provide a progress status in those 30 seconds it's getting ready to terminate. That way I wouldn't have to remember "nohup" or "tail". I don't spend that much time on linux lol. Are you sure ESXi has nohup and tail? I was trying "screen" per someone's suggestion, but appearently esxi didn't have that feature. In face, even better would be running xsibackup with no arguments and have it show running backup satus and progress without terminating anything.
#2 General matters » Viewing running backup processes, status and progress » 2019-10-18 03:06:40
- Tin-Man
- Replies: 3
I ran the backup from and SSH session by hand, but I imagine that scheduled ones I'll encounter the same problem. I know the backup is running becasue when I try to run the xsibackup command again it wants to terminate it. So, how do I see the process, it's current status and backup progress? My vmware performance counters show a big drop in disk activity so I'm concerned it's stuck waiting for something or frozen or something like it.
BTW, on my original command arguments, I included STDOUT so that I could see the progress, but got disconnected and now I'm on a whole new SSH session.
#3 Re: General matters » Are we there yet?... » 2019-10-01 19:14:11
We have delayed the launch date, sorry about that but we are a small development team and we want to make sure that all details and features are there.
Apart from that we have to eat and cannot finance development with 100% of our time.
The version number lets you know the development stage, currently in beta phase 0.9.7.3
You could pre-sell licenses (and unlock the beta limits with an expiration date) or better yet, get crowd source funding by launching the product on Indigogo or Kickstarter. That might help grease the wheels, speed things up, and make sure nobody starves in the process. Just an Idea.
#4 General matters » Are we there yet?... » 2019-09-29 01:35:29
- Tin-Man
- Replies: 3
So, I didn't realize the software was in beta at the time (something you guys should mention on the website or documentation, or anywhere!), but I have several clients already sold on this backup solution. So when is it going to be ready? Cuz they're asking me on a regular basis now. As it stands, I can't even use the trial to demonstrate it, because with it's current limits it's only usable in a lab testing environment.
#5 Re: Speed » Achieving maximum speed » 2019-08-28 02:07:33
LZJB compression is almost RAM fast.
There isn't any menu in XSIBackup-Datacenter, it's all command line driven. In any case it's use is much simpler than XSIBackup, thus incorporating a menu wouldn't be as useful as in the case of XSIBackup-Pro
You are correct, I had to swtich to XSI Pro to get usable results. XSI Datacenter's limits are too stringent to generate even a single usable backup outside of the lab and no logs are being generated despite verbosity set at 10. Not very good for obtaining authorization for purchasing, the whole point of a trial is to see if it will work, not just in a lab on test VMs, in production on live servers (outside of operating hours of course). But from what I've seen, the backup operation won't even start if the VM is larger than 60GB, so there was no attempt to create a backup at all, no log entries made, no partial backup to analyze performance, no nothing.
#6 Re: General matters » Datacenter Trial limits? » 2019-08-28 01:47:55
Yes, you can remove the limits for 6 h.
How do I remove the limits for this time frame? Including the 60gb limit.
/
...
Latest version allows to backup up to 60 GB.
Yes, thank you, 60gb is a little bit more helpful however! when the trial version encounters a VM that is over the 60GB limit, it quits completely without considering the size of the rest of the VMs in the list! Do I have to setup a diffrent job for each and every VM? Becasue from the looks of things, it might be that XSI Datacenter will stop all backup activity when it encounters an error of any kind and will not continue on to attempt backup of any other VMs.
#7 Re: General matters » SEGFAULT condition was trapped » 2019-08-28 01:35:52
Nevermind, figured it out. So one thing you guys might want to clarify in your documentation regarding the source when using a directory format /vmfs/volumes/VOLNAME/FolderName/VMName is that if this format is used, XSI Datacenter will search for a vmx file in the directory in order to determine what VM to backup. I was pointing my directory to the root of the VMs folder hoping that it will backup all the VMs without having to list them out as I would with the "VMs(...)" format. Which brings me to my next question, how do I set XSI to backup all VMs on the host without specifying each one? VMs get moved around and added and deleted all the time, having to modify the backup every time there is a change would be irritating to say the least.
#8 Re: General matters » SEGFAULT condition was trapped » 2019-08-28 01:18:43
I'm getting this SEGFAULT as well, however I am backing up from ESXi to a Synology. The synology is mounted in ESXi as a an NFS Volume. Do I still need to somehow add a key to my Synology? I wouldn't think so because the connection to the synology is already established, XSI should be able to just treat it like a local volume no?
#9 Re: General matters » DC v Pro » 2019-08-25 20:16:01
Yes, there will be a discount equivalent to what you paid for your Pro version. You are right the DC version simplifies things a lot as it only has two methods: --backup and --replica.
We are taking the time to test it in the multiple combinations that ESXi can generate since v 5.1.0 although as it mainly relies on GLibC that makes it more stable, it still relies on the underlying ESXi folder and descriptor files structure.
We should be able to launch by middle August.
Middle of August? lol
Do you have a new estimated time frame?
#10 General matters » Datacenter Trial limits? » 2019-08-25 19:15:40
- Tin-Man
- Replies: 2
Ok, so I put this backup software to run some real world test only to find that the Trial limits to only running for the first 6 hours after reboot and only 40GB VMs. Making it pretty much unusable. So then I check to see how to get a license and no license available yet!?!?
So, is it possible to remove the time and size limit for the Trial for a limited time? or Can I purchase a license now? or how can I get this software closer to production testing or use?
Is Datacenter just a beta right now?
#11 Re: Speed » Achieving maximum speed » 2019-08-25 02:14:16
...
• In case you find yourself in a situation in which you are limited by some single core performance limitation..., just disable --compression on your backups ...
XSIBackup-Datacenter is a silent backup service in the background, it does not want all cores in your server, it does not need them, it must not use them. Your processing power must remain available for your services, not for some service that is overutilizing CPU in your server when it doesn't need it.
XSIBackup-Datacenter does not need more than a Pentium single core to achieve maximum speed. You should only bee concerned about your CPU if you are, per instance, using some Atom CPU or some ancient XEON.
...
While I understand that the core of XSI Datacenter is quite efficient and may not need anything more than a single core, XSI Datascenter as a whole seems to incorporate more. Compression for example is something that can be very taxing in processing, depending on the compression settings. In fact, as it stands right now, from what it sounds to me is that compression is already the "bottleneck" of the backup operation. While I understand that it's possible to move the compression task over to the receiving server, this is not always an option, especially with cloud storage solutions. I personally prefer to set Backup operations to high priority so as to complete the backup task as quickly as possible. I'm not sure what the disadvantage of making XSI Datacenter multi-threaded other than spreading a small load across cores.
In any case, XSI Datacenter is extremely fast and quite good. I wish the menu options were more complete to match all the command line switches and email server settings, but I'm sure that will come in time.
#12 Re: Speed » Achieving maximum speed » 2019-07-12 16:52:08
It sounds like XSIBackup-Datacenter was made to only use a single thread on a single processor, how come? In today's server environments it's not so much about getting the highest gigahertz processors anymore, most of us running cloud services often look for higher number of cores. Does this mean that if I got a 32 core processor only running 1.2ghz each that XSIBackup-Datacenter will not perform well?
Pages: 1