Jump to content

Ramon88

Members
  • Posts

    410
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Ramon88

  1. Take a look at page 274 of the Retrospect User Guide. Retrospect saves a backup copy of the config file. But it's a good idea to backup these config files themselves.
  2. Are you backing up to tape? If so; - Did you erase the tape before use with Retrospect? - Did you mislabel the tape?
  3. Well, to be honest those topics are more about "Sleep" and not so much about waking up a client. But indeed, one would like to have it all in one working package as they are both relevant when trying to run with a greener footprint. Actually I think it's quite strange this has not been implemented (successfully) yet...
  4. Thanks Russ, I wasn't sure that was still current, we only upgraded to 7.7 recently (7.7.325 to be exact). Too bad it's still broken. However the program should be relatively easy to fix if it times out too quickly. At least one would think so.
  5. Does anybody successfully have Retrospect initiate Wake On LAN for a client? We seem to have no success so far, while we can wake up those machines by a regular WOL command (not involving Retrospect). I'm not sure if this has already been mentioned elsewhere on the forum. It would be very nice to have this working (as well as the 'sleep after backup' function). Used versions: Windows Multi Server 7.7.325, Windows client 7.7.106 and OSX client 6.3.028. Server OS used is Windows 2008 R2 STD x64. Client OS's are various: (OSX 10.4, 10.5, 10.6 and Windows XP, Vista, Windows 7, Server 2003, 2008 and 2008 R2.
  6. Did the system crash because of the faulty PSU? Maybe you are seeing the results of that crash. Did you already run checkdisk?
  7. These files are lost links found by checkdisk (chkdisk). They can be anything like open files, temp files, documents etc. that were lost during a system crash. You probably can delete them, but if they are giving you this kind of trouble when Retrospect examines them I would think your disk might be suspect. A fresh disk would be an option indeed.
  8. I would like to second that. This has been a long time wish for us. Well, there are more important things, but if you take a good look at the problem at hand, it shouldn't be too problematic to make this feature work. On the other hand, it might be more complicated to arrange than we, the end users, think.
  9. This has been the case for a long time. We run Retrospect under its own user account and have been doing so for quite some time. One drawback is if you, for example, have rebooted the backup server and have Retrospect running as a service, if it is executing a scheduled backup you can't access the Retrospect program/user interface itself. If you try to launch the program in such case, the OS will inform you the current execution will be stopped. Well at least that is the case with 7.6.123. We haven't tried it with 7.7.325 yet, but I expect it to be the same. We leave the program always 'open' so we can always access the interface.
  10. We've updated the drivers and firmware to the latest available ones. I regret to say: no dice... For us this is a bit of an annoying problem.
  11. We have a Retrospect server running with the E5620's predecessor, the E5520, in a dual socket setup. We also do use AES with Retrospect. However the current engine doesn't use all the available resources. When running a couple of execution units, it seems it only uses two cores or so. My suggestion is, at this time, to get the fastest running dual- or quadcore cpu. In this case I mean raw GHz. So the Xeon E5520 will probably be outclassed by a faster running i7. I'm not sure what the future brings though. Maybe the next major release will be better able to use more resources...
  12. We use tape eject in many of our scripts. Tape Drive: StorageWorks LTO-4 Ultrium 1760 SAS Internal HBA: HP SC44Ge Retrospect version: 7.7.325 (x64) Driver update & Hot fix 7.7.3.102 (x64). Retrospect server OS: Windows 2008 R2 Server (x64) Strangely enough eject using "Storage Devices" > "right click Eject" works (after rewinding). Is this a known bug or is there something else going on?
  13. We have it running now. Only had problems with about 30% of our local clients when pushing Windows client update 7.7.106 resulting in the clients running said client, but the upgraded Retrospect server not seeing them, reporting error: "Sorry, can't change network access for XXXXX, error -560 (invalid private/public key)." We solved it by uninstalling and reinstalling those clients on the client machines itself (so no push update). We'll let it run for a couple of days and probably will update the remote infrastructure to 7.7 as well. Used versions: Windows Multi Server 7.7.325, Windows client 7.7.106 and OSX client 6.3.028. Server OS used is Windows 2008 R2 STD x64. Client OS's are various: (OSX 10.2, 10.3, 10.4 and Windows XP, Vista, Windows 7, Server 2003, 2008 and 2008 R2. The error mentioned did occur on various (Windows) client machines running different OS's. We couldn't determine a common cause as to why the error occurred.
  14. We've decided to take the plunge and upgrade from 7.6 > 7.7. However we've hit a 'snag'. For this specific topology we use two Retrospect (multi) servers. One server is located at our office, the other is a remote system (datacenter) connected with a enterprise class leased line (fiber) to our office location. The remote Retrospect server backs up the remote infrastructure and stores its data locally (at the remote location). The second Retrospect server backs up our office and development infrastructure. Besides that it also backs up the same remote clients as the remote Retrospect server does, using the leased line. This gives us a couple of performance and redundancy benefits. Now we want to start upgrading our local Retrospect server form 7.6 > 7.7. This is not a problem, but the question is if it can work with the remote clients that still need to run 7.6.106 instead of 7.7.106. Because those remote clients need to work with both Retrospect servers (and thus Retrospect versions). Is this possible or do we need to upgrade our entire infrastructure in one go?
  15. What kind of verification do you use? There are two possibilities: - media verification - thorough verification In my experience verification errors are to be taken seriously. There is a big chance this problem is not caused by Retrospect, but it can also be very hard to trouble shoot. It may be defective hardware causing it, or software like drivers. Because a server is a complex system of components (hard & software), tracking the problem down can be a lot of work and may require certain expertise which you might lack (no offense intended).
  16. I've replaced the PSU from a white Intel iMac last year. It was quite easy when you know what to do. The most fun was to replace the HDD for a faster one from a Mac Mini. Had to use a stripping knife to open the case. Opening current full body aluminum iMacs might be a challenge though. I believe it involves big suction cups to lift the glass plate from the front... Never tried that. Anyway, if you are up to it follow this link and pick the mac in question. then click on the "Hard Drive Replacement" icon/picture and it will show you a step by step guide with pictures. Have fun! :teeth:
  17. Not sure what you are seeing exactly... Is it this issue? If not, maybe you can post a screen dump?
  18. When I check out their app in the appstore they say Windows based Retrospect support is in the works. so it's only a matter of time. Would like this also, but quite frankly they should -also- support Windows Mobile. I think there are more system engineers with that type of smartphone out there. But hey, it's free! Can't really 'demand' it.
  19. 1) Will fit any CD-R (this has always be my guess). 1a) As far as I know this is not possible. 1b) See 1a. :teeth:
  20. Well, at least you know what was wrong! We had two system crashes in two days after we updated the network drivers. We rolled them back yesterday evening and reconfigured the NIC's to their old settings. Now we see the problems again. But RSS is switched on (default setting after driver up/downgrade). We'll test for a couple of days if the system is stable again (it did do all backups correctly last night) and if so, switch RSS off. As for the problem of it not showing up. It does that, as far as I know, only when setting up the first time. It's easily remedied by the 'USB trick' though. Performance is highly 'erratic' It depends on the type of data we backup. But we also use data encryption on all our backups, so that slows things down. There are two switches between the server and DroboPro. There is approximately 70 meters of Cat6 S/FTP cable between the server and DroboPro and it is actually in the next building for security purposes. To give you a more reliable estimate, a normal file copy is about 65MB/sec (but we have seen >80MB/sec). But performance in Retrospect can be much less. For regular machines we usually get ± 1 GB per minute (including media verify). For developer machines and servers it can be less, depending on the number of (small) files and the matching time THAT takes (a real drawback of Retrospect imho). But we sometimes also see figures of more than 2 GB per minute. I don't have exact numbers, but if I would need to estimate it, running two execution units simultaneously maybe has a 25% performance hit. Three maybe another 25% based on the figure of two, and so on. It depends on a lot of factors. One of these is Retrospect itself. I think it could be made a lot faster by using more resources. But that is another discussion altogether. DroboPro is what it is. It probably could be created with faster components, but for what it is and costs it is a nice deal. But I feel Retrospect itself is the bottleneck at this time. For now we can live with that.
  21. Well than, in all likelihood you probably didn't understand my last remark... Good luck in getting your device to work!
  22. It could be a coincidence, but after updating the DroboPro with the 1.1.5 firmware our backups took a lot more time. We noticed by monitoring the data flow for the iSCSI NIC there were severe drops in the link. So we had a look in the Event Viewer and saw a lot of Errors with iScsiPrt. Now, you will get those once in a while and that's not really a problem. But these were a lot! Our solution was to disable Receive Side Scaling (RSS) on the NIC providing the server with the iSCSI connection. It so happens a lot of people using iSCSI devices are having this problem and it is not limited to DroboPro hardware. The iSCSI protocol seems to tax all network hardware and RSS seems to have an adverse result. Maybe this is useful information for people having trouble with their iSCSI devices.
  23. I was afraid you were going to say that. We probably lucked out at the first install of the server. But the new drivers (and our reconfiguring) has interfered with the order of NICs. In the meantime we manually configured all clients (30+). Feels a bit 1990's though. Maybe it's better to make this a couple of feature requests: - The possibility to define the default NIC in Retrospect. - The possibility to apply a selected NIC to a group of clients (also without the need to redefine client IP's)
×
×
  • Create New...