Jump to content

bnj

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About bnj

  • Rank
    Occasional Forum Poster
  1. Multiserver 7.6.123, Hot Fix 7.6.2.101 Ca 120 clients are backed up every day in a staged manner with ca 20 disk backup sets that are transferred to tape twice a week. I have one backup set where (huge) clients are written directly to tape. All the backup sets are recycled every ca 3 months in order to clean up and to keep the tape backup set at a reasonable size. After 3 months we have about 20+ tapes with 300+GB. The tape catalog is then 6-7GB. Retrospect has become much more stable over the years since when we started in 2005. I have no real statistics, but I think the program now crashes 1-2 times per month. I think you should put some work in getting it even more stable, but especially more bulletproof to crashes. Very often when the system crashes, the catalog files are messed up. When an action is done on a retrospect file I suggest that you keep a copy of the old one until the operation is successfully done. I have a backup script for the tape catalogs and other Retrospect files, but they are not always accepted by the program when I restore them. Right now I am close to do a recycle, but the tape catalog was corrupted after a crash. The dialog boxes for recatalog are telling me to do strange things that are not possible. Sort of "select most recent member" where the OK button is then greyed out. I don't want to create a new tape backup set without having a working catalog file for the old one. I am recreating it now, but it could take a week before it is finished reading all the tapes unless I want to set the alarm clock to every 3 hours so I can login and klick OK to go using the next tape (already sitting in the robot). So PLEASE change the way you handle files. Let there be virtually no risk of loosing files if the program dies. This also goes for all the other Retrospect files like Config75.dat, which i managed to restore from the backup. It was still so corrupted though, that it crashed the program everytime Retrospect started backup. I stopped all operations and could print out all the settings on paper. Then I manually had to start all over to connect all clients, put them in backup sets, recreate selectors etc. It took 1-2weeks work before the system was running as before. We have have 2 NAS disks that I planned to use, but Retrospect seems to be very sensitive to disturbance of the network connection. The problem might be on the NAS, but a normal windows connection works fine. It seems that Retrospect cannot recreate the connection during a backup session. You have a good product now with many ingenious features, but please make it more bullet proof. Best regards, Brian
  2. So now things are lightening up!!! I was reluctant to update to the latest 7.5.387 version because of the disasterous 370 update. I have now updated from the earlier version 324 to 387, since I found no reports of large disasters. The memory leak problem seems to be solved, so it WAS a bug! The program has been running now for 2 days and the memory use doesnt seem to increase. Now I hope there is no other/new problems emerging... After this short period of testing is seems that Retrospect is really doing what it was promised to do when we bought the first verisoin more than 2 years ago. Oh yes I claim that version 7.5 was merely a bugfix, we had to pay for. I am happy about the future, but disappointed it should take so long to get here. Thanks for everyones inputs and suggestions. /brian
  3. A short update: It seems to me that it is when backing up clients, the memory is locked up and never released. Heavy grooming and transfer activity doesnt seem to influence the memory use in the longer run. We have 8 250GB disks arranged in 4 stripes. If it is coupled to hardware/drivers, maybe one should look for the raid controlers or the network cards. /brian
  4. Hi Lennart You might be right, but the leaked memory is released when restarting only the program and in the task manager the memory is reported to be held by retrospect. I will try and make a log over some time... /brian
  5. Hi all I went back to the earlier version and now I am back with "only" the old problems that I described before. Richy Boy Look here: http://kb.dantz.com/article.asp?article=9607&p=2 I installed the extra 2TB so I am good for a while I guess. I tried to make a safe VB script that could restart Retrospect every second day or so, but with no succcess... The problem with the memory use is the same as Fletchi18 described. The memory is used, but not released again, even if the software is idle. The memory is released only when restarting the program. In the old days (Before version 7.0), one could see the progress of the program by monitoring the memory humps passing by in the Task Manager. Now it is more a line slowly climbing only with smaller modulations. /brian
  6. Tjenare Lennart! You might be right (or I hope so). When I look in Windows Task Manager it is Retrospect.exe which hold the memory though. When I restart Retrospect it is released. I dont have to restart the server. We are regularly checking for updates for the hardware, so far without any effect on this problem. Since the last update I also have a suspicion that the disk sets are growing faster. We have just bought 2TB more disk space that we will install soon. Since last summer it worked sort of OK (except for the memory leak and the usual irritations), but the last 1-2 months it has been a real pain. There is a lot of minor things I would have made different with the program, but that is another discussion. I am thinking mostly on the user friendlyness and some reporting and summarizing features that would be neat and nice. /brian
  7. Dear friends I am getting more and more frustrated about this software. We have a multiserver licence with most addons. We are backing up ca 100 computers, win, mac linux. The server is an XP box with 2GB memory and 2TB disks that are "transfered" every day to tape. The server is not doing anything else than this. For the price of the software I think it is really not working well enough. Since the last update I have had nothing but work to do with repairing catalog files after numerous crashes. Retrospect funny enough asumes it dies because of power failures. Buffer overrun it says sometimes. Before the latest update we also had version 7.5, which we paid for about a year ago. 7.0 was a very, very! slow mess. 7.5 is faster, but still not good. There is a memory leak that eats up the memory after some days, which means I have to restart the program several times per week in order to avoid crashes. This problem has been there at least since v7.0. We paid quite some money to get the "upgrade" from 7 to 7.5. I claim that this was more a fix, since the program started to do some of the things 7.0 was promised to do, but couldnt really because of the slow program and gui. This program really has some nice features, proactive backup, transfer to tape, multi threading (although I am not sure it uses all available CPU's if more than 1), etc. If Dantz, EMC or insignia, (whoever it is right now) cannot make this working soon, we have to start looking for alternatives. This is getting far too expensive to use. I would expect to use somthing like an hour per week to check that things are progressing, put in new tapes and add/modify clients. The last month I have probably used in average 2-3 hours/day and there is still a lot of clients that are not backed up because of corrupted index files for the disk backup sets and now also the tape set. I cannot repair the catalogs faster than they are messed up by retrospect because of crashes. I have decreased the number of used threads from 8 to 3. It seems to help on the buffer overrun issue. I am sanding in... Maybe it is so that Retrospect is not really meant to be used for so many clients? If so, please let me know! I would guess the server could serve at least 200 clients if only the software was not giving us so much touble. Desperate Brian...
  8. bnj

    Hangs with 100% CPU while grooming disk

    I gave up grooming. I tried with all the different update versions of Retrospect. One of them helped (During the summer as far as I remember), but it is still far too time consuming for me. OK they say it takes time to groom. How many weeks should one wait then with 100% CPU usage before deciding the system has hanged? As far as I see it, it doesn't work in reality. My solution was to buy 2TB of disk space and then recycle the disk backup sets every second month or so. Giving suggestions to Dantz, results in absolutely no response. (just as the progam often does) As far as I see it, Life is too short for this. I let Dantz debug this. I have other things to do. The program has some really nice features and ideas. Unfortunately the good picture is distorted by seemingly really poor programming. Brian
  9. We wil have to live with that problem with retrospect I guess. Some of our computers take a lot longer than this. You can reduce the time somewhat by excluding "Temporary Internet Files" for each user in the clients. To me it seems it is the number of files and not so much their size that take so long when the snapshot is being build. Some of our client computers have Matlab installed. There is a help or toolbox library containing about 80000 files. This takes a lot of time every day if you do not exclude those libraries in the client program. It doesnt help to do it on the server, because it will browse the libraries to build snapshot even though the files themselves are not backed up. I gave Dantz some suggestions on this, but they are about as responsive as their program sometimes ;-( To me it looks mainly to be a windows client problem. /brian
  10. Some tasks take a very long time on the server. More information showing the status of tasks would be nice. Keeping an eye on the memory use with Task Manager in windows one can check if things seem to progress, but it doesn't give any hints on when a task is finished. The transfer utility should show some numbers so we can see how far a task is. Currently the grooming utility does this. An estimated finishing time would be neat. Sorting the items in the tabs in the Activity Monitor by clicking the columns should be possible. New feature: A tab with warnings when A client is not connected to a backup set, A client is never backed up, A disk backup set is nearly full. Etc. A separate thread for the user interface would be good, to increase responsiveness. A deeper reference manual /help system is needed. What happens in detail when grooming, transferring etc. More information for the interested user is needed for the fine tunig the backup system. Being able to kill a task in the "Executing" list when it has hung, without disturbing other ongoing tasks. (OK that was a little sarcastic )
  11. Transfering from disk to tape is one of the bottle necs. I suggest that the receiving backup set keeps track of the snapshots it already contains, so the software does not need to search through all the files in the source backup set. Only newcomers need to be checked. Sometimes a transfer can take hours now, even if it turns out that no new files need to be transferred. Furthermore I suggest that a buffer file is used during transfer so the tape backup set is not locked for hours and hours with very little actual activity. This way several transfers can be prepared at the same time. Maybe this buffer file could be used so that it could be put on the server with the tape station by other servers. The tape station server could then write to tape each time a buffer file and the tape station is ready.
  12. Building snapshot from Windows clients is one of the bottle necks in the backup. I suggest that the clients are more active, so the information is ready when the server connects. This could be done using the same feature as the virus programs. Every time a file is touched, the client should be noticed, so it can keep a list of changes since the last time it was backed up. For some reason the mac client is much faster at this.
  13. Well... I groomed once with good results friday. It was faster than before and it didn't get stucked at some position as before. I started grooming another disk backup set and it seemed fine, but now (monday morning) I can see it has been running at 100% CPU for the whole weekend. I had to kill the program, since not even the user interface was responsive. It seems we need a bug fix to the latest bug fix... We are going to install another 1.2 TB in the server, since the need for grooming is increasing. One full backup of all computers leaves only little space for incremental additions. This is not a solution for the grooming problem, but it reduces the frequency of the need for grooming. If this is a lingering problem, I am very disappointed and I will probably have to do with recycling the sets in stead of grooming. Dear Dantz, When I bought our system I was concerned about the tape station, whether it was fast enough. The bottlenecks where surprisingly the server software and the PC client software. The MAC client software is much faster. Some weeks ago I submitted a longer comment on the feedback page, but this page seems to be neglected from Dantz. You don't even get an automatic answer that they have received the text. Please comment on your plans regarding all this. /brian
  14. I had a similar problem with one client. It turned out that the firewall, ZoneAlarm was installed and the necessary holes where not there. As far as I remember there were several holes to knock before it worked. Jus a suggestion :-) /brian
  15. Hi there Is this released soon? We really need this, since we have the same problem (among others). We have a server with 1.2TB disk space 2GB RAM. 65 clients of various OS's, up to 10 computers in each disk backup set. Grooming, transfer to tape and snapshot retreiving are the bottlenecks. The tape Catalog file is now ca 8GB. I guess this could be a problem, but I cannot see how to prevent that... Brian
×