Jump to content

Ramon88

Members
  • Content count

    410
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Ramon88


  1. You might want to check related posts in the Server, SBS and Multi Server forum. In general 8.1 beta is more stable than 8.0 release. However installing is not as easy as release software (especially with the clients). Instant Scan is problematic. For correct function of Retrospect 8.1 I recommend disabling Instant Scan services.


  2. Since we've disabled Instant Scan altogether we seem to have the same product as before. It seems about the same as Retrospect 7.7... After all our troubles that seems to be a pro. Sad actually...

     

    We currently don't get Network Communication Errors.

     

    We use 8.1.0 (209) for the server and 10.1.0.187 (OSX) / 8.1.0 (209) (Win) for clients.

    All on a 64-bit 2008 R2 (STD) server.


  3. Don't bother. Instant Scan doesn't work as advertised at the moment. It sometimes works and sometimes doesn't. It causes other problems as well.

     

    However if you can't resist the urge to test its functionality (or rather disfunctionality), more information about ISA and the ISA database locations can be found here: http://kb.retrospect.com/articles/en_US/Retrospect_Article/Retrospect-InstaScan-FAQ/

     

    Currently we have its services disabled as it's flakey. It doen't always run, its database can get corrupted easily, and we've seen it adding all files to an incremental backup, thus creating full backups every time instead (and as such negating the prospect of having a faster backup completely). It shouldn't even have been in the 8.0 release and as 8.1 it indeed is beta-ware, so handle with care.


  4. Is there a performance benefit to leaving them uncompressed?

    Dunno, Is there by compressing them? :P

     

    I would wage the pro's and con's a bit. I'm not sure how much you actually gain storage wise by compressing the catalogs. This feature has been in Retrospect for ages and probably isn't really needed anymore because storage is so cheap today. Also the program defaults to uncompressed, maybe for a reason? Having said that, I would expect such a feature to be unproblematic. If it is, rather avoid it if possible.


  5. Speed depends on many factors such as cpu and i/o speed of the client, as wel as the backup server, and if encryption and/or compression are used. It also depends on the kind of files being backed up, a lot of small files are slower than a couple large files.

     

    We get around 40MB/sec for encrypted disk-2-disk over a gigabit LAN for the faster clients. If we don't encrypt the speed actually depends on the i/o speed of the client (the backup server has faster i/o). However some clients are a lot slower, especially developer workstations with a lot of small files. That is where Retrospect is 'weak'. Especially when building catalogs, the system is waiting a lot and doing little.

     

    Lennart is right however, it would work with 10 megabit, even slower (for example VPN's) works.


  6. Did a little more digging. It seems this technology is native to LTO drives: http://www.ultrium.c...gy/primer3.html

     

    It seems that the LTO just does this as part of its function and it can't be disabled.

     

    The question remains if this method is as reliable as running a verify. Probably not, but it can be sufficient for most needs. Another way of looking at it is this: The drive makes sure the data that it has received and caches in its memory is written to tape. This is what it actually verifies. However it can't know for sure if the data it received (and caches) is exactly the same as the backup program has sent to it.

     

    So, if you don't do a verify run you're for the most part protected from bad tape errors this way. It checks for this. But it doesn't check the whole dataflow from the backup program to LTO drive, just the same as MD5 verification isn't 100% reliable, but maybe 99,999%

     

    So yes, it is less reliable, but only a little bit. Just the same as MD5 verification is. If you want 100% reliability you need to do full verification. It's up to the admin to make that choice and do a trade off between risk and efficiency.


  7. During the years of Retrospect usage we kept adding exceptions to our own filter. For all errors, we just check the log manually, every day. If that would work for you depends on the amount of machines you need to backup. It's something we just do every day. We do not use the email notifications for that. With those one can only see a bit in advance if there were many problems or not. Just log into the backup server and check the log.


  8. Hmm, I give up. We're seeing very weird behavior with Instant Scan running. When backing up a large local directory with SQL backups to LTO Retrospect 8.1 is always in effect creating a full backup (it wants to copy all ±350GB of data to tape, every time :blink: ). So after disabling ISA in services and making sure both 'ISA' processes are not running it will run as it should.

     

    So, with ISA running: it wants to backup everything again, even right after it has finished its backup run. And with ISA not running, the second run doesn't yield any new files to backup (as expected).

     

    Now the big question: WHERE CAN I GET MY MONEY BACK! (I never yell on this forum, but this time I did feel like it... :angry: )

     

    We're now going to disable the ISA service on all our servers and workstations (don't forget to reboot). Backups will probably go quicker this way, when it doesn't needlessly add files to a given backup. Why did I upgrade again? O yeah, because Instant Scan would shave precious time from our backups... NOT.


  9. Not sure if this is the right part of the forum for this question, but here I go.

     

    The other day I had a discussion with our system engineer about our backup verification process. Usually we always do some sort of verification. For disk-to-disk we do the MD5 verification and for LTO-4 backups we do a regular verification run after the actual backup.

     

    However LTO drives have a feature that's called read-after-write where the backup in progress is immediately read by a specialized read head. In short it should be possible to do a backup without another verification run. Thus cutting backup time roughly in half and doubling your drive and drive head life span.

     

    The only thing we don't know is if Retrospect actually uses that hardware feature of LTO. So can we safely uncheck verify on our scripts for LTO backups or not?

    • Like 2

  10. Yeah... same here. I'm looking around for options. One of our two remaining Retrospect backup servers is already gone. That platform was replaced with dual VMware vSpheres with Veeam for backups. Never looked back. That solution just works and is extremely quick. However Veeam only works for virtual platforms (VMware and HyperV), not for bare metal desktops and servers. Nor mixed environments (Windows and OSX). And it has no tape support, which we need for some clients (real offline storage).

     

    I'm regretting my decision buying the Retrospect upgrade. 8.0 is beta-ware and 8.1 isn't much better. I rather would have sticked to 7.7 and saved the money. I've been a Retrospect user for ages but I'm afraid this way it's credit will go down the drain very quickly. If people don't buy it, the company (and product) will fail. And I can't blame people for not buying it at this time... :(


  11. Well, we've upgraded too... And indeed had to do everything twice because we installed 8.0 and then did the 8.1 prerelease update. So far I'm inclined to agree with Richy_Boy. I don't have the feeling I'm actually using a new major release. It feels like a small update with problems to boot. Although we are still looking into the performance gain from Instant Scan. If it works well enough and is a little bit more stable than 7.7 I would probably say it's worth the money. But we're not there yet and so far I'm not blown away at all. We're having the same problems as mentioned on this forum. I'll get back to that in a few days when I've gathered more information.


  12. I just installed the new iOS app. However while syncing the app freezes and Retrospect itself crashes (eventually) to the desktop after it produces an error window: Assertion failure at "datetime.cpp-836". After I restart Retrospect the iOS app unfreezes and tries to connect again. Any ideas?

     

    Retrospect used is Multi Server 7.7.620 on Windows Server 2008 R2.


  13. We've been using a leased line (optical fiber) for two years. We use it to backup remote servers. It used to be slower than a file copy (±11MB/s for file copy, ±5MB/s for Retrospect) but this was workable. We do a lot of other things over that 100Mbit line, so it wasn't a problem when Retrospect doesn't use the full bandwidth.

     

    However we recently had a Leased Line platform upgrade and there will be another one coming up soon (where the provider will switch to Cisco MPLS).

     

    It seems that since the platform upgrade our Retrospect speed has plummeted to a mere 2MB/s at best, while a regular file copy still does ±11MB/s. It's driving me crazy! :angryred:

     

    After a lot of testing (also using different hardware) we suspect there might be a problem between the Retrospect's way of communicating and the Leased Line.

     

    Our Leased Line provider has asked us to provide them with the specs of the communication protocols (RFC's) used. They want to take a closer look at the problem, together with their Cisco engineers, and without those protocols that's not going to happen.

     

    B.t.w. this Leased Line is completely transparent. So it's kind of weird we're seeing this anyway. It only seems to happen with Retrospect, everything else works without problems.


  14. That's weird because our test clients (running 7.7.114 client) seem to work fine with 7.6.123 Server?

     

    The problem which we face is a weird one. We think using the 7.7.114 client helps. 7.6.106 clients do not work well with 7.7.341 server in this setup.

     

    The problem is related to our leased line (fiber). Since upgrading our local server to 7.7.341 performance over this link is extremely poor (to the point of unworkable). In the beginning of a run performance is okay. But after some time (random) performance slows to a crawl.

     

    We did many things to isolate the problem. So far what seems to help is using the 7.7.114 clients and using Retrospect's link encryption.

     

    We did reinstall a test server on completely different hardware (in a VM) and experienced the same issue. It's really weird. Normal file copy over this link between the same server and client (server) works like a charm.

     

    Also we did experience a weird problem with our LTO-4 drive using 7.7.341. Snapshot transfers (3 source snapshots to one tape backup set) resulted in a "Waiting for Media" message when the first snapshot completed. But the tape was erased and not nearly full at all.

     

    What did change to our LTO-4 drive was the firmware, as HP recommended (U57D). Could be causing this too.

     

    However the LTO-situation is unrelated to this topic, but it illustrates the problems we have since installing 7.7.341 a bit.

     

    The fact I'm going on a holiday at the end of the week doesn't help either! :D


  15. For an application we have two Retrospect servers in the same network. One is a 7.6.123 Multi Server, the other a 7.7.341 Multi Server.

     

    Can we update all clients to 7.7.114 and expect 7.6.123 to work correctly?

     

    The point is both Retrospect servers need to be able to backup a certain group of the same clients.

     

    Updating the 7.6.123 server isn't an option at this time.

     

    We did test this config with a couple of clients and it seemed to work. But before we run into problems I'd like to know if it's advisable. ;)

×