Jump to content

cmcfarling

Members
  • Content count

    46
  • Joined

  • Last visited

Community Reputation

2 Neutral

About cmcfarling

  • Rank
    Occasional Forum Poster
  1. cmcfarling

    Open File Backup

    So more specifically. Does Multi Server utilize VSS when doing a backup if the Open File Backup add-on is not active? I tested this and a ton of required system files were not backed up due to the "sharing violation" error. Below are a few lines from the log. Wouldn't there be no sharing violation errors if VSS was being used? File "C:\Boot\BCD": can't read, error -1020 (sharing violation) File "C:\Boot\BCD.LOG": can't read, error -1020 (sharing violation) File "C:\System Volume Information\DFSR\FileIDTable_2": can't read, error -1020 (sharing violation) File "C:\System Volume Information\DFSR\SimilarityTable_2": can't read, error -1020 (sharing violation) File "C:\System Volume Information\DFSR\database_D8A8_B3A8_A8B3_8392\dfsr.db": can't read, error -1020 (sharing violation) File "C:\System Volume Information\DFSR\database_D8A8_B3A8_A8B3_8392\fsr.log": can't read, error -1020 (sharing violation) File "C:\System Volume Information\DFSR\database_D8A8_B3A8_A8B3_8392\tmp.edb": can't read, error -1020 (sharing violation) File "C:\Users\admin\NTUSER.DAT": can't read, error -1020 (sharing violation) File "C:\Users\admin\ntuser.dat.LOG1": can't read, error -1020 (sharing violation) File "C:\Users\admin\ntuser.dat.LOG2": can't read, error -1020 (sharing violation)
  2. cmcfarling

    Open File Backup

    Is the Open File Backup add-on required to backup open files when using Multi Server on Windows? For example, if Multi Server is installed on a Windows 2008 server, is the Open File backup license required in order to create a full back of the local drive that would be useful for disaster recovery?
  3. No, there is no reference to any .rdb file.
  4. I changed the logging level to 7 but did not get any additional info. I then tried changing the log level of Engine, Trees and Volumes, Backup Sets and Catalog Files and Networking to 7 as well, which still did not generate any useful info in the log. The only additional entry that appeared was xipSetDevice: can't seek, error -105 (unexpected end of data) Any other suggestions?
  5. Due to Retrospect's imperfect grooming feature, disk based backup sets don't always get groomed thoroughly causing disk backup sets to fill up. Once this happens the catalog must be rebuilt in order to perform a successful groom operation. I've had to go through this procedure several times in the last 18 or so months. Normally the rebuild completes with no problems. However, I have a catalog now that will not rebuild. I'm using the Repair Catalog >> Recreate from disks command to recreate the catalog from the disk based backup data. Once Retrospect gets to the point where it begins to read the backup data from the disk, the following error come up: Device trouble: 1-Production2, error -105 (unexpected end of data) The disk is good working order. It is used for backup data for several other backup sets as well, all of which are functioning without problems. I've run chkdsk on the disk also and it checks out fine. Does anyone have any experience with this particular problem? Any suggestions for getting this catalog to rebuild at this point without having to wipe out all of the existing backup data and start over from scratch?
  6. cmcfarling

    Grooming failed, again

    Yes, "Keep the Catalog File compressed" is selected for the backup set, and all of my backup sets for that matter. It always has been and I've never seen this error before, through many catalog rebuilds. Storage space is not an issue here, there is plenty. For an excruciatingly detailed overview of my setup see these posts: http://forums.dantz.com/showtopic.php?tid/26204 http://forums.dantz.com/showtopic.php?tid/26354
  7. As usual, grooming has failed to work as expected. On 7/21 the grooming policy dictated that an automatic grooming should be done on one of my backup sets. As is common, it failed with error -1101 (file/directory not found). I then started the normal procedure of recreating the catalog. After that ran for 13:42:43, I then ran a manual groom operation on the backup set. That proceded to run for 12:41:17 before it failed with this error: Grooming Backup Set Production1 failed, error -2242 (Catalog File duplicated or ambiguous) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. Can't compress Catalog File for Backup Set Production1, error -1 (unknown) Sweet!! So here we go again, looks like I'm in for another day of rebuilding/regrooming and keeping my fingers crossed. Meanwhile data hasn't been backed up for 4 days. Are any of these well documented grooming issues addressed in 7.6 I wonder?
  8. I've been getting this error message intermittently. Here's a log snippet: 1/31/2008 8:04:27 PM: Copying Web on C on server02 1/31/2008 8:04:27 PM: No files need to be copied 1/31/2008 8:04:35 PM: Snapshot stored, 30 KB 1/31/2008 8:04:46 PM: Execution completed successfully Duration: 00:00:18 (00:00:09 idle/loading/preparing) 1/31/2008 8:04:48 PM: Copying backup on C$ on server01 Scanning incomplete, error -1020 (sharing violation) 1/31/2008 8:04:49 PM: Copying CTuner Setups on C$ on server09 Scanning incomplete, error -1020 (sharing violation) 1/31/2008 8:04:50 PM: Copying ORIS on Output on server09 Scanning incomplete, error -1020 (sharing violation) I'm curious as to why it's failing on the scanning phase. I talked to tech support and their explanation was this... When Retrospect is scanning the folder, one or more of the files in the folder is in use by another process. As a result Retrospect is deciding not to backup the entire folder. He went on to explain how an application can communicate directly with Retrospect to inform it of files that are in use. To the best of my knowledge that may be the case if I were using Open File Backup, but I am not, which I explained to him. On top of that the source folders involved wih these 1020 errors are always SMB shared folders on a different server than the backup server. Even with OFB, if Retrospect is running on server02 and wants to backup an open file via SMB on server01, is there any way for server01 to allow that to happen? His explanation doesn't really make any sense to me. Why would Retrospect skip an entire folder if (potentially) just one file in that folder is in use? Why would it not go ahead and backup the files that it can and skip the file(s) that have an open file lock on them? Was I perhaps misinformed (again) by tech support or is that really how Retrospect works? To note, All servers involved are running Winows 2000 Server. If I go to Configure>>Volumes, I can browse any of the remote folders with no problems. Again, this happens intermittently. Sometimes these source folders backup with no errors. It seems to me that there is something else wrong and that this is not just standard behavior.
  9. cmcfarling

    Grooming fails to start in some cases

    If you read through this thread I'm not asking how things are supposed to work. I know how things are supposed to work. I'm asking why things don't work as they are supposed to. It seems to me that for anyone trying to implement a backup system beyond something fairly basic, Retrospect tends to fall on it's face, or at least require a lot of babysitting. There are several threads on this forum that support that statement I think. That's not the kind of backup software most admins want to deal with. By posting my findings here, calling tech spport on the phone, emailing you directly, I was hoping to spark some interest from the support and/or development departments to try to make this software better. I don't know, maybe some of this has filtered through. From my perspective though, I get the impression that support doesn't want to be bothered with these "annoying inquiries by that guy who owns one copy of MultiServer." After all they have better things to do like get v8 out the door, right? Nothing personal, it's just frustrating when you know something should be working better and there is no real recourse to make that happen, especially after investing a great deal of time and money.
  10. cmcfarling

    Grooming fails to start in some cases

    Quote: It is very unusual to have anyone saving 70 snapshots for EVERY hard disk you backup Why? I've had a similar setup for years when backing up to tape. The source volumes are publicly shared volumes. Users on production desktops work directly from these network volumes. Since files are constantly changing, being deleted, added, etc throughout the day, backing up the sources once a day is not adequate for an effective recovery policy. For these production volumes, I'm backing them up 5 times a day at approx 5 hour intervals. By keeping 70 snapshots per volume that allows at least 2 weeks of backed up data. On the other hand, I also have backup sets which backup just once per day and are set to keep 21 snapshots (3 weeks). Here's an overview of my setup BACKUP SET SCHEDULE SNAPSHOTS TO RETAIN SIZE LIMIT ---------------------------------------------------------------------------------- Production1 Sun-Sat 1AM,6AM,11AM,4PM,9PM 70 1800G Production2 Sun-Sat 3AM,8AM,1PM,6PM,11PM 70 3000G Production3 Sun-Sat 5AM,10AM,3PM,8PM,2AM 70 1500G Operations1 Sun-Sat 8PM 21 100G Operations2 Sun-Sat 8PM 21 200G Databases1 Sun-Sat 12AM,12PM 28 100G Quote: If you backup Drive C 71 times and Drive D 71 times, then the unique data that exists in the oldest snapshot will be groomed out. Grooming will only happen when the disk actually fills or if you schedule a grooming operation. Yes I realize that Quote: You mention that Retrospect may not have retrieved all of the snapshots after you made a setting change. Are the "inactive" snapshots all IDENTICALLY named from the same source volume? Yes, they are identically named. And, I didn't mention that Retrospect may not have retrieved all of the snapshots, I mentioned that it didn't retrieve any snapshots. What about all of the other issues with Retrospect NOT doing something it is supposed to do as I've oulined in this thread? I can't help but get the feeling that no one at EMC is going to take 2 seconds to try to reproduce any of these issues. Am I wrong? As I've been beta testing, er um, trobleshooting over the last month or so, the recurring theme from EMC tech support is that all of the problems are with my configuration, my hardware, my backup strategy, etc, etc, etc. If I am pushing Retrospect beyond its limits then how would I know? Where is the documentation stating what the limits are???
  11. cmcfarling

    I am getting tired...

    While I see that most of the posts on this thread are from mid 2007, most of the gripes still apply today I think. Namely the stuff about bugs and the inordinate amount of time that too many admins have to spend babysitting Retrospect. I've had my own issues; grooming problems, constant corruption, UI glitches, etc, etc. Chris
  12. cmcfarling

    Grooming fails to start in some cases

    If you recall from post #105225 - 01/07/08 01:37 PM above, I had changed the snapshot count from 35 to 70 for the Production1 backup set. That's when Retrospect told me it was going to retrieve older snapshots so they wouldn't get groomed out, which of course it did not do. Then this whole progression of trying to force Production1 to groom started with the intent that maybe Retrospect would retrieve those older snapshots as part of the groom process. Well... that didn't work out so good. The backup set went from having 83 snapshots total to just 40 now. In other words, after changing the snapshot count from 35 to 70, the backup set contained 35 active snapshots and 48 inactive snapshots. Retrospect was supposed to retrieve 35 of the 48 inactive snapshots to make the total number of active snapshots 70. After doing so a groom operation would have groomed out the remaining 13 snapshots. Instead those 35 (+ the 13) were never retrieved and were groomed out leaving just the original 35 active snapshots. At this point 5 new snapshots have been created for a total of 40. So not only does grooming fail to start sometimes, you will potentially lose data unintentionally if you can get it to work. Sorry EMC but it may be time to look at other options.
  13. cmcfarling

    Grooming fails to start in some cases

    Update... The Production3 groom operation finished after 16m at 1/8/2008 8:00am. As of 1/8/2008 9:47am the Production1 groom operation that was stuck in the waiting queue is still there. Let's try stopping the proactive backup yet again and see what happens... Finally!! The Production1 groom operation moved from the waiting queue to the executing queue. I don't know what else to say that hasn't been said. There are some serious issues with this software to the point where managing groom enabled disk backup sets is almost undoable.
  14. cmcfarling

    Amazing recatalog speed

    No, single disk. Yes, "all disks" was selected.
  15. cmcfarling

    Grooming fails to start in some cases

    Update... The Production1 groom operation finished after 2h 23m at 1/7/2008 8:18pm. As of 1/8/2008 7:43am the Production1 groom operation that was stuck in the waiting queue is still there. Let's try stopping the proactive backup again and see what happens... Amazing, after stopping the proactive backup, a groom operation for yet another backup set, Production3, has started executing. Again, where did this mysteriously come from? And of course the Production1 groom operation in the waiting queue is still there. It just gets better and better (or actually worse and worse).
×