Jump to content

mnc042

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mnc042

  • Rank
    Occasional Forum Poster
  1. Ah, got it. That definitely makes sense. Thanks. \marc
  2. Good question! Nope, running on Windows XP Professional, SP3. So that shouldn't count as the "server", right? \marc
  3. Okay, I have a question about how my licensing works. I currently am running my Retrospect server with a license for Retrospect Single Server, Windows version 7.6.123. As I understand it, this product can back up ONE server, and unlimited clients. So I'm currently backing up 10 clients -- I look under the License Manager, and it shows I am using 10 backup clients (of unlimited, included with Single Server), and it indicates NO server clients. Now, I want to add my one server. But when I go to add a server client, it asks for a new license, and won't let me back up my server (which is MacOS X "Snow Leopard" Server 10.6.1). Did I misunderstand the way the licensing works for Single Server? This may be -- and if so, what's the easiest way to add support to back up a single server to my unlimited clients? Thanks! \marc
  4. mnc042

    7.6 Linux client broken

    You are correct! I'm not really sure how it happened, but the old Retrospect daemon had never stopped. I did a manual kill -9 on the old client, wiped any vestiges of the old Retrospect client off the machine, and did a fresh reinstall. That came up without issue. All is good here. Thanks for your suggestions and help!! \marc
  5. mnc042

    7.6 Linux client broken

    I guess I am confused and/or unclear on this.. This is not using the GUI per se. It is the retrocpl binary, but when called without any arguments, it is supposed to check the status of the daemon and exit (as per the manpage). The GUI is never launched. In fact, retrocpl is the command that is called from the /etc/init.d/rcl script. Thus, if you do: # service rcl status it ultimately calls: status) $CLIENTDIR/retrocpl ..which gives you the error above: [root@inara ~]# service rcl status 1215407027: pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes Retrospect client is not running And it reports the client is not running when, in fact, it is. Again, this is NOT running the GUI. And, this command is failing when it is doing its handshake with the Retrospect client daemon. So I'm wondering -- what is that error, and why is it failing? Are you saying that the entire retrocpl binary is broken in 7.6 and that, inadvertently, this breaks the status check command? Thanks again! \marc
  6. mnc042

    7.6 Linux client broken

    I did. This happens on a clean install. Looks like the retrospect control panel can't talk to the retrospect daemon. Any other thoughts? What does this error mean? Thanks! \marc
  7. mnc042

    7.6 Linux client broken

    I can pitch in here a little bit.. I installed the client on Fedora Core 8, and it works for backup. The problem seems to be when I go to check the client status, and retrocpl is invoked. When I try to check the status of the client, I get this: [root@inara download]# /usr/local/dantz/client/retrocpl 1215377555: pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes Retrospect client is not running [root@inara download]# Ah, but it is running: [root@inara ~]# ps -ef | grep retro root 1868 1 0 Jun28 ? 00:11:53 /usr/local/dantz/client/retroclient -ip 192.168.0.63 -daemon root 27236 1868 8 17:01 ? 00:00:09 retropds.23 root 27254 26298 0 17:03 pts/1 00:00:00 grep retro Okay, so it's running but the retrospect control panel can't figure that out. So what's going on? Doing a system trace on retrocpl tells me that it's something network-protocol-related that it doesn't like. Here's what I see. First, retrocpl connects to localhost port 497: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(497), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 Then, it does some handshake over the connection it just opened, and fails: send(3, "\0e\0\0\0\0\0\0\0\0\0\0", 12, 0) = 12 recv(3, "\0\311\0\0\0\0\0\332\0\0\0\0", 12, 0) = 12 recv(3, "\0\22\0\0\1\0\0\0\1\0\0\0\0\4\0\0\0\1\2\7\0\0\0\0\0\0\0\0\0\0\0\0"..., 218, 0) = 218 send(3, "\0\236\0\0\0\0\0\0\0\0\0\0", 12, 0) = 12 recv(3, "\0\312\0\0\0\0\0\4\0\0\0\0", 12, 0) = 12 recv(3, "\0\0\2(", 4, 0) = 4 time(NULL) = 1215377415 write(2, "1215377415: ", 121215377415: ) = 12 write(2, "pmcTrans: requested 158: expecte"..., 78pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes ) = 78 What's the client sending back to the control panel over localhost:497 that is causing it to fail here? \marc
  8. D'oh, didn't think to look in that section. Thanks for the reply, this helps a lot!! \marc
  9. Was there also supposed to be an updated Mac client that goes with the 7.6 server? The client listed on the Downloads page is dated 2006.. Retrospect Client for Macintosh 6.1.130 2006-05-04 Is this actually the latest client for MacOS X? \marc
  10. Hi, Checking on this issue since it's been two months since last post.. I notice the beta Retrospect mentioned that resolves this WMI repository error still hasn't been released yet. I'm on .508 and getting the WMI error, and was wondering when the fixed release was going to be.. well.. released? :-) Thanks in advance! \marc
  11. mnc042

    Grooming - Out of Disk Space

    Windows temp is on c:\WINDOWS\TEMP, the same volume with 35 gigs free. I suspect Retrospect had enough scratch space to do its work, but the volume that it was doing the work on exhausted its free space -- the one down to just over 2 gigs. Unfortunately, when it failed, it corrupted the catalog. I'm going to try to re-do my backupsets -- start over -- but this time, instead of taking the default grooming policy, I'm going to have it groom to the last 10 backups. I think that should prevent it from running out of room again. Via the default policy, it seemed to have kept something like 25 backups total, stretching back to early February. Although -- once again -- I thought Retrospect was supposed to automatically determine how much it could keep based on disk space. I'm really confused as to why the disk volume that the backup set is stored on, when it ran out of space, caused the exact condition that I wanted to avoid by turning on grooming. If you had any thoughts on that and how I could use Retrospect in a more effective way, I'd really appreciate it. Now, I'm just kinda baffled. Thanks for the help, everyone! \marc
  12. mnc042

    Grooming - Out of Disk Space

    But where is this work done, on the C: drive? My C: drive is intentionally very small, about 40 gigs total. I have about 35gigs free, although my catalogs must be getting pretty large. Can I tell Retrospect to do its scratch work on another volume? I also seem to have completely lost my backup sets.. Retrospect will not rebuild the catalog, says they are corrupt. That's disappointing, I wouldn't expect a condition like being out of disk space to completely trash the backups I've been doing. Anyway, thanks in advance. \marc
  13. mnc042

    Grooming - Out of Disk Space

    my C: drive is rather small, only 34.3 GB free on that volume. Could that be the problem? My backup volume currently has only 2.58gb free; will it ultimately free some space on there to make room for new backups? Thanks in advance! \marc
  14. Hi all, OK, I thought I understood what Grooming did but maybe after last night's run I'm not so sure anymore. Got a Retrospect 7 server backing up several Linux machines and Macs/PCs. Goes to a large disk (400GB), with the backup set policy set to take 99% of the disk, default grooming policy is activated. All went well until last night, when I see in the logs an error: "Grooming Backup Set Homenet01 failed, error -1115 (disk full)". I thought the whole point of grooming was to keep as many backups as possible, but pull space out of the backpset until the disk again had enough space? Why did I see this error, and how do I now recover from it? My backupset says it has 2gb free. Will the default grooming keep pulling older backups out until space is again recovered? Thanks in advance! \marc
  15. Hi, I must be doing something wrong. I have several clients being backed up to Retrospect 7 disk-to-disk. I am using the proactive server mode exclusively, because it seems to do a good job of distributing the backups over the backup window. On a few machines, I have specified multiple volumes to be backed up. (/home1 and /home2, for example). The problem is: When I go on to a specific machine, open the Retrospect control panel, and change the option for proactive backup to be "as soon as possible", the machine gets backed up -- but only ONE volume of the multiple ones listed for that machine! It's as if the proactive server picks the first volume randomly (/home1), backs it up, then sets the control panel back to "on normal schedule" and the second volume never gets backed up by the "as soon as possible" request. Is this normal behavior? How can I have a machine get all its volumes backed up when setting the control panel's proactive backup request to "as soon as possible"? Thanks in advance! \marc
×