Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Ramon88

  1. Well, we have to consider the fact that major software changes do take considerable time to develop properly. And to solve the important issues, major changes are possibly what's needed. So no quick fix will be at Roxio's disposal, nor would they want a quick (but dirty) fix I would think. I feel EMC didn't do Retrospect a lot of good. Roxio deserves the chance, but it will take time to fix the problems. Of course this is kind of bad considering some of use have been waiting for a long time to get the fixes and updates. However this can't really be helped I'm afraid.
  2. Indeed, breaking up into parallel backups could be your solution. Your enemy will be fragmentation, but you can avoid that by creating separate storage targets on your SAN. And if you don't groom, fragmentation will be a lesser issue I suppose. Our (main) backup server also has an aggregated link to the core switch. This can improve performance a bit too. Remember the bottleneck will be the clients. For all our OSX clients we also have a separate Time Machine storage target. Actually that is located offsite through the fiber optic line. That way we have a complete redundant storage solution apart form Retrospect. Very nice for the sysadmin as well, because users can restore their own files if need be, and a backup interval of 1 hour. Quite cheap to set up. We like our eggs in many baskets! :teeth:
  3. Fortunately for us, we don't need a lot of server power for OSX, so we got a simple 2010 model of the Mac Mini. Uses less than 10W when idle, maybe 25W peak. We only use it for OSX archive storage. So nothing fancy is needed. OS can be updated for only a couple of bucks (we use regular OSX, not the Server version). We thought Helios was way to expensive and I don't think there are many alternatives left but ExtremeZ-IP. For what it is, it's quite good. But because of lacking Spotlight performance we dumped it. Of course we use a Windows 2008 R2 server for SMB file sharing, AD etc. Our solution probably isn't the answer for you guys. But you have to be wary when Apple updates their OS (Lion anybody) and you will be sure to get problems with ExtremeZ-IP compatibility with OSX which can take ages to get solved, if ever. It would have been so much more convenient if Apple and Microsoft would have teamed up and made sure AFP over TCP would have been working out of the Windows 2008 box. Well, maybe it will happen as Apple seems to stop making Xserve systems. But that's probably wishful thinking.
  4. We have used ExtremeZ-IP for about 5 years and never ran into trouble when restoring files using Retrospect. You can easily test this by backing up (ExtremeZ-IP) server based material and restoring it to an OSX client. Unrelated however, we recently switched back to a stand alone Mac Mini as a server because it wasn't that expensive (compared to ExtremeZ-IP ocer a couple of years) and is waaaay faster when using Spotlight (unless they solved that bug during the last year). For storage we used an iSCSI target controlled by ATTO Xtend SAN iSCSI initiator. :-)
  5. I think we are in the same boat. We too have to back up a very large volume each day. Therefor we utilise multiple backup servers and multiple storage targets (iSCSI HDD RAID5 storage). We even go as far as running our backup targets offsite using fiber optic leased lines. And we also utilise a secondary backup platform (non-Retrospect) that creates restorable incremental images of all our servers and workstations each day. To top that off we transfer our most important data offline to LTO4 tape each day as well. We might be paranoid about this all, but our data means a lot to us and our clients. RAID6 would be only 20% slower than RAID5, so I don't think it will be the bottleneck. However client performance surely can be! Especially when backing up large amounts of small files (developer machines). How good is your storage at concurrency? You could try to break up your clients into groups and different storage sets and do two or more simultaneous backups. It sounds like your storage should be up to that task, so why don't you try that? Seems like a waste of time to do everything in a serial fashion. Do you need to do a full backup each day? We use incremental backup each day and groom out everything older than 15 backups. We also use two or even three sets, so we can go back in time about six or more weeks if need be. Using our tapes, we can go back even further if need be. When coping with bandwidth problems you need to adjust you backup strategy. Divide and conquer! :teeth:
  6. I probably should have said something like this: less cores with higher frequency is preferred over more cores at lower frequency. Those CPU's are often cheaper as well. We get highly variable results, depending a lot on how many and how large or small the client's files are. MD5 verification however is always fast. Easily doing even 2000-5000MB/min, sometimes even faster. To get a more stable figure I would need to do a recycle backup. Our OSX clients are faster than our Win7 clients as well. My own machine (OSX) is reliably pushing more than 2000MB/min and it's not even directly connected to our core switch. This is an AES-128 encrypted backup, mind you. As are all my figures. This specific Retrospect server uses two hexacore Xeons, but we will move Retrospect to a different machine with only one socket and a Xeon X3470 next week. Because we use encryption for most of our backups we're sure it will be faster at a lower tco. The dual hexacore machine will be used as another HyperV platform. To test your throughput I would create/use a (fast) client and create a backup folder with a few, but large files (ISO's for example). Switch off encryption and compression and see what you get. Btw, the real time backup performance indicator is notoriously inaccurate. There are also other factors, like subspec network switches, network cards and drivers. In other words, your mileage may (and will) vary. :teeth:
  7. Hmmm... Rich actually has a good summary of important shortcomings. I agree for the most part. Retrospect saved my day on a couple of occasions. But it is also seriously lacking. It's a bit of a love-hate relationship I suppose. Because I have been using it for at least 15 years now I understand its shortcomings and power. However it needs slightly more than a spit and polish to become future proof. I really hope the Roxio-situation helps. Time will tell. If I had to decide right now without my Retrospect history I would probably not end up with it. But then again, the grass is always greener on the other side of the fence.
  8. All true and well, but this is far from saying "2008 is based on the Vista kernel which is a faulty design". Ahwell... I'm afraid the original poster didn't even read the discussion nor the suggestions.
  9. Stating something IS a fact isn't the same as IT BEING a fact. If your machine came with plain 2008 that is what you probably want/need to work with. It's only logical the R2-version is more advanced/stable because it has been released a lot later. When the next version will be released that will obviously be better than R2 as well. We use many servers and I'm not seeing 2008 being less stable than 2008 R2. However I do admit our Retrospect servers are using the R2 version of the OS. And while in theory I could go to bed with anyone I want, I wouldn't because I'm a happily married man.
  10. We can get between 1000-3000 MB/min using iSCSI storage. It depends a lot on what one has to backup. Matching phase can be a big slowdown. Bottlenecks are/can be your CPU. Retrospect doesn't really utilise multi-core technology that well. So generally speaking higher frequency CPU's will be faster. Using software encryption is a performance hit, as is software encryption. To speed up you can try using 'Media verification' instead of 'Thorough verification'. Remember to set 'Generate MD5 digests during backup operations' in Preferences to use this feature.
  11. Implying Server 2008 has a "faulty design" because of it being based on the Vista Kernel sounds very besides the point/truth... Firewall issues might be the cause, but maybe it's something entirely different. Does the Retrospect server use multiple LAN ports? Which Interface is chosen ("advanced button" in Network Access within Retrospect), Does a direct IP entry (numeric) work instead of "Multicast"? Can the new server access regular Windows shares on the network the clients are on? Lets start with these options first before shouting at Microsoft...
  12. Did you set the Backup Set's properties correctly? You have to tell it how much disk space it can use. Backup Sets (window) > Highlight the Backup Set in question > Properties (button) > Members (tab) > highlight the member in the list > Properties > Set the "use at most" setting. What grooming option do you use? We have experienced setting it to "Groom to Retrospect defined policy" will result in something ungroomable in the long run. For that reason alone we use at least two alternating backups so we can confidently recycle one if need be, or periodicaly. Or just use the "Groom to remove backups older than X" option instead. You have to remember for performance issues grooming isn't 100% efficient and depending on mutating backup data the grooming algorithm used can get overwhelmed so to speak.
  13. As an alternative for the time being I can recommend Microsoft backup for the HyperV host. :-) If your VM's are 2008 based they too can use MS Backup themselves. We have all 2008 machines (either normal or virtual) push file and image backups using MS Backup to iSCSI targets. Out of the box MS Backup does full backups. However look for the performance setting in the Server Manager > Windows Server Backup > Actions > Optimize Backup Performance > Faster backup performance. This will create very fast incremental block-level backups. Using System Restore you can even reinstall a complete server from a Windows Server boot disk. Depending on backup settings of course. Here we use both Retrospect and Windows Backup on all 2008 machines, so we have two independent technologies backing up these. The only drawback is you need more storage space, but that's quite cheap these days.
  14. I'm not sure if writing to optical media has anything to do with this. Maybe you could investigate this by trying to back up that substantially growing item(s) to a file storage set? As Russ explained it's quite possible/normal already compressed data to grow when compressing it again. While most ZIP compression is quite efficient, real time compression algorithms are less efficient. This is logical, because otherwise compression would take too big of a performance hit. The compression algorithm used by Retrospect is probably a run-length encoding (RLE) algorithm. One question though. Is the original data stored in a compressed folder in the operating system (Windows)?
  15. Maybe you should try to (free) update to Retrospect 7.6.123 and see what happens?
  16. True enough. But we do not do backup of systems during office hours.
  17. Please define remotely. If you have RDP-access to a client and have the right credentials you can remotely install the Retrospect client. However if you want to use that remote client the question is what kind of network-medium you will be using to transport the data from the remote to the Retrospect server. If it's the Internet you better create a VPN-tunnel between them. And in most cases, depending on the specifications of this connection, it can be quite slow. As far as I know, it's standard not possible to preconfigure the client. But I suspect it can be done if you know how.
  18. There are many things you can do, and all have their own consequences. To get useable advise it would be wise to include more relevant information about what -you- want with your files. Maybe you just need more storage to meet your needs. Maybe you need to transfer or archive. Do you only need to have a backup, how 'deep' in time should it be? Did you also take a look at the Retrospect 'grooming' option? If you have no need to keep older (source deleted) files this might be the best option. If you need to keep everything safe, you need more storage. Does it need to be offline (tape) or online (disk)? As you can see it depends an many factors. Without context its near impossible to give you the right suggestions.
  19. Personally I think client/user popups from Retrospect are not really needed anyway. It's the system engineer/admin's job to look at Retrospect's backup log to determine if everything went well. Just my personal opinion. Other situations might be different.
  20. Let us know how that fares. to be sure, the error you mentioned, is it only occurring when backing up to tape?
  21. Looking at those logs I believe the problem is only with 'open files'. Open files are caused when client users are logged in or software like antivirus is running. Without the open file backup option for Retrospect you will not be able to backup those files. However, these are (most of the time) less important log files and alike. You could create a filter (Edit script > Selecting) for your Retrospect scripts (Configure > Selectors) to exclude those specific files/directories. Works for us like a charm.
  22. I believe Robin is suggesting to run the latest version your client is eligible to download. Not to buy 7.7. right away...
  23. Hehehehe, good thing it was something logical in the end and not a vague bug! Now if Restrospect had a functioning "sleep client" option you wouldn't have to deal with these shutdown scripts. Setting up clients to make sure they don't sleep or shutdown at the wrong time can be bothersome sometimes...
  24. If your backup config file is corrupted as well and you have no copy of a working one laying around, you indeed have no other choice but to start from scratch again. Good luck with that!
  • Create New...