Jump to content

utig

Members
  • Content count

    11
  • Joined

  • Last visited

  • Days Won

    1

utig last won the day on February 28 2013

utig had the most liked content!

Community Reputation

1 Neutral

About utig

  • Rank
    Occasional Forum Poster
  1. both c: and d: are recent crucial m4 256G's with updates, but not the most recent. creating a .rbc file of similar name works fine from Notepad. If retrospect creates a new catalog file elsewhere, and it is then moved to the ssd, it works fine. And once created, none of the 20 or so catalogs have any unusual issues.
  2. over the last few months, when I create a new catalog in RS 7.7.620 on my catalog ssd, it says that d:\ is a malformed name. If I then go back and put it anyplace else, the create succeeds. I then cut and paste from anyplace else to d: and RS is happy ever after. I think this started back when I was still using a 15k rpm disk for d:, but I can't swear that's true. d: is a 256G ssd less than half full. Windows server 2008. chkdsk d: is fine. Once created, there are no issues with catalog files. Any ideas at all welcome. Mark W.
  3. utig

    Retrospect On Ssd

    I tested an early version of a cheap MLC ssd and the write speed was inadequate. Recent MLC ssd's have fixed this, as well as reliability issues. I've been using 15k rpm sas disks (one for C: and one for catalogs) for several years, and Retrospect is able to drive them at about 1/3 to 1/2 their native data rate when performing catalog operations, like snapshot delete, rebuilds etc. My initial impressions with ssd were favorable compared to these 15k disks. Make sure you choose a large enough one if you compress your catalogs- my two 136G disks are both about half full, with my largest catalog being about 18G (compressed). when rebuilding catalogs much of that 65g free space is used before they are compressed.
  4. Although I could never isolate the problem with the linux server which crashed during Retrospect backup, swapping out to a spare system fixed the problem, now for many weeks. Sorry, Retrospect, for jumping to conclusions...
  5. We use our windows 2008 server to back up 5 linux boxes, CentOS 4 and 5, 32 and 64 bit. On one, a CentOS5x64 system, crashes occur while being backed up, sometimes after a few (~20) small files. Retrospect just thinks the network connection has broken; there's not much info in the logs of the system crashing. This has also happened to a 32 bit RHEL4 system, but much less often (2x this year?) The other Linux systems with similar OS configurations (but different client hardware) continue to backup without a hiccup. 7.6.123 server 32 bit, linux client 7.6.100
  6. utig

    Server and Retrospect Upgrade

    Before you commit to a one-way conversion to 7.7, I'd urge you to read the forums carefully. In particular, I'd be sure I were in a position to: 1) restore the old os and retrospect environment 2) have time enough to rebuild all the catalogs in case 7.7 doesn't work well in your environment and you have to revert back to 7.5 My experience going from 7.6 32 bit to 7.7 64 bit and windows xp to windows server 2008 64 in early 2010 was painful. 7.6 works well under 2008 and I'm still contemplating the move to 7.7 with trepidation. I know some of the issues I had with early 7.7 are claimed to be fixed. Maybe. good luck, mw
  7. I'd like it if catalog rebuild did not scan rdb files which are not in the relevant folder. On a big raid disk with lots of archive sets, it takes a long time to wade through all those un-needed files.
  8. Another vote for multiple snapshot delete. I've wasted hours pruning backups.
  9. utig

    Slow matching under 7.7?

    so - who has actually tested the 3/21 release and found that it addressed their slow matching issues? I'll be darned if I go through that agony again without some expectation that it will improve things. 7.6 has remained fairly stable for us (few crashes in 4 months, and no failed catalog rebuilds) - the reasons we originally went to 64 bit 7.7 in January.
  10. utig

    Slow matching under 7.7?

    we had this problem in early January. it was impossible, and we downgraded to 7.6 to fix it. Some data: we had ~10 backup sets with about 1TB of data each, 500 sessions, and about the same number of snapshots. 7.6 groomed each in an hour or two; we gave up after 3 days under 7.7. There has been a patch release since then, but I'm going to wait until someone else tests it... Actual backups (matching) had what seemed to be the same fundamental problem. There also seemed to be much more multi-thread overhead than in 7.6; one groom used 25%user+3%sys on a 4 core box; two grooms used 40%user and 20%sys. all this on w2008server64bit. 7.6 works much better.
  11. utig

    Best Practice question

    a word of caution: when you rebuild a catalog, retrospect 7.6 and 7.7 scan every file on a disk, not just the ones in the particular backup set. If you have a large disk with many backup sets, this can be quite annoyingly slow.
×