Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About jlg

  • Rank
    Occasional Forum Poster
  1. Hopefully Dantz fixed the grooming bug in the latest build; we'll see pretty quickly. Regardless of that, though, the fact remains that if a disk backup set gets too large, or at least if the catalog file gets too large, then R can't handle it. I had a disk backup set that was almost 2Tb, with a (locally stored) 5Gb catalog file, and R just wouldn't open the thing. The server has 2Gb RAM. I hope Dantz doesn't seriously expect us to buy a cop-out like, "You need at least as much RAM as the size of the catalog file." That's crap. I don't even think R was grooming the backup set, since it hadn't completely filled the disk yet, and I think this is part of the problem--the size of the backup set isn't the only limitation; R needs to groom the catalog file as well, because if that gets too large, it won't matter how much space is left on the disk because R won't be able to access the catalog! I'm trying a different method, creating multiple smaller disk sets, limited to 250 or 500Gb each, and splitting the backup jobs between the sets. This should reduce the size of the catalog files to something R can manage. At least, I hope so. It shouldn't have to be this hard. We're looking at a data lifecycle management solution so we can get something reliable for our data, and leave just the simple stuff to Retrospect. It's apparently just not built for heavy lifting.
  2. Well, this problem needs to be addressed soon. My daily b2d backups just aren't happening unless I manually open the properties of the b2d set every day.
  3. Once the size of the backup catalog reaches a certain magic number, Retrospect has problems accessing it. Backup jobs going to that backup set simply sit in the "waiting" queue waiting on the backup set to be available, even though the catalog and backup set files are online. Calling up the properties window of the backup catalog takes several minutes, as does changing to any of the various tabs within the catalog properties dialog. Once I change to another tab of the properties dialog, though, it is as if I have forced Retrospect to admit that the backup set is really available, and it will start the waiting backups. I don't know what the "magic number" is, other than to say that my catalog file is almost 5Gb in size, and the backup set has 3227 files on disk taking up 1.46Tb. The catalog file is local on the Retrospect server, and the backup set files are on a Windows shared network drive across GigE.
  4. Just for the record, it would be nice to have a way to access the hidden preferences without having to use a funky key combo that's not always accessible from a remote console or KVM.
  5. The catalog file is local, it's just the disk set itself that's across the GigE connection. The set was created in the last rev of Retrospect, which Dantz admits had several problems with disk backup sets. I created a new disk backup set on the same volume, local catalog file, same deal, and that set now has 650+Gb and the catalog is 800Mb, and it's acting normal. So, I suspect that the problem was that both the old catalog and the backup set itself (since a recatalog didn't help) are in bad shape. Thankfully it's an offsite backup that can be replaced easily; if it had been a critical archive, I don't know what we would have done. I have set the new catalog file to groom to the last 14 backups rather than using the Retrospect default; I'm not sure that I trust the defaults at this point. That's what I get for using rev 1 of a new feature, I suppose.
  6. jlg

    Is EMC trying to kill Retrospect?

    I've seen similar issues with catalog rebuilds and large disk-based backup sets. Retro 7 doesn't like large disk-based backup sets (>1Tb), or at least it doesn't like large catalog files (>1Gb compressed). Viewing the properties of a large catalog file takes ~10-15 minutes for the properties window to come up, and the same amount of time to switch between tabs within the properties window--that's 10-15 minutes per mouse click, and it ultimately just stops doing anything, Retro stops responding and has to be killed. Rebuilding the catalog file results in the "white screen of death" where the Retrospect application window goes white and doesn't appear to be doing anything. Then there's the spurious "serious errors" that cause Retro to crash unexpectedly, buggy handling of some tape libraries, and other niggling issues including tech support that says, "Gee, that's odd" instead of offering meaningful assistance. I have to agree with jhg on this one. Retro 7 has some serious issues.
  7. Fulls work, partials don't. Apparently it's a problem with the Master database not wanting to submit to a partial backup. Stupid MS/SQL...
  8. So far, the only way I can get a good Exchange Server backup is to do a full. Partials won't work, even after a full. Then again, Retrospect likes to die a violent death on a regular basis too, so there are obviously other issues with the software...
  9. I have a large disk-based backup set, comprised of ~4700 files and ~1.2Tb in size. The Retrospect server accesses the backup set across a GigE network on a Windows file share hosted by a Windows 2000 server in another location (it's an online offsite backup). Retrospect chokes when it does anything with this backup set...even opening the properties window of the backup set takes 10-15 minutes, and the same amount of time to switch between tabs or make any changes in the properties window. When Retrospect scans the set for grooming, the main Retrospect application window goes blank white, and *might* refresh every half-hour or so. It's unusable. The wrong response is what I got from Retro support in Europe, which was essentially, "Why would anyone have a 1.2Tb backup set?" They're in France, which I suppose could be an excuse for giving a stupid answer, but that's still the wrong answer. I want to know if Retrospect is supposed to be able to handle large disk-based backup sets, and if not, why not.
  10. jlg

    Does Retrospective 7.0 Actually Work?

    Retrospectively, it sort of works. As long as you can babysit the server and the clients, and your hardware is all in perfect order, then Retrospect can be made to run pretty well. It does a lot of things very nicely, better than many high-end "enterprise" backup solutions, in fact. I replaced Veritas BackupExec with Retrospect, and my life is definitely better. Online purchasing & download, setup and configuration, hardware compatibility are all strong points. Retrospect is still not ready for prime-time in the enterprise, though. Leave Retrospect to its own devices for 24-48 hours, and you're as likely as not to come back to a bunch of failed and/or waiting backups and an error dialog that's holding up the works. Dantz still does not grok the concept of a hands-off backup server that does its thing, sends email when it hits a nonfatal error, and keeps on going with the next job. No, Retrospect pretty much dies at the drop of a packet, as it were, and then doesn't know what to do, doesn't email anyone, just sits there doing nothing. Perhaps it's attempting to achieve nirvana or something; if that's the case, it's doing a great job. Even if you set the prefs to their maximum "no feedback required" configuration, it doesn't stop Retrospect from throwing up a dialog box and waiting for its keeper to click the mouse. Hello, Dantz! I want a backup server that doesn't NEED a mouse. The GUI is great, but its use needs to be OPTIONAL.
  11. I'm running the v7 Retrospect agent on a Dell PowerVault 770N NAS device, trying to backup a couple hundred Gb of data. This particular host is "Windows Powered," meaning the OS is non-standard, modified by Dell to optimize filesharing performance on the PowerVault system. Several other Windows servers (running 2003) backup properly, but this one crashes after Retro backs up ~4400 files. Turning off the Retrospect agent and backing up using the UNC network path works fine (other than a handful of inaccessible file issues). The event log shows a bugcheck. Where should I start looking? Are there any known issues with Retrospect and "Windows Powered" versions of Windows? I purchased ASM, and I've contacted Euro support via email, but they basically gave me an "RTFM" response--considerably less than helpful--and U.S. support kept me on hold so long that my IP phone finally dropped connection. Grumble.
  12. Retrospect does not seem to be backing up SQL databases. In the backup job setup, I have entered the sa account & password, and the authentication works properly. When the backup job starts, it successfully enumerates all of the databases on the SQL server, and it attempts to backup all of them, but the log shows the following information for each database: - 3/7/2005 6:42:37 PM: Copying TAMUQ Training on data Backup type: Differential 3/7/2005 6:43:00 PM: Execution completed successfully Completed: 1 files, zero KB, with 0% compression Performance: 0.0 MB/minute Duration: 00:00:23 (00:00:19 idle/loading/preparing) I know that these databases have changed since the last backup. Why is Retrospect not backing anything up? (And I've read the latest memo on only doing full backups to disk-based backup sets; once I can get it to actually back up something, I'll modify the scripts...at present, this problem occurs regardless of the backup set type.)
  13. Differential. Here's what I see in the log: - 3/7/2005 6:43:49 PM: Copying First Storage Group on mail 3/7/2005 6:43:49 PM: Connected to mail Backup type: Differential Trouble reading files, error -3714 (Some log or patch files are missing) 3/7/2005 6:44:20 PM: Execution incomplete Remaining: 1 files, 17,179,869,184.0 GB Completed: 2 files, zero KB, with 0% compression Performance: 0.0 MB/minute Duration: 00:00:31 (00:00:25 idle/loading/preparing) Aside from the -3714 error, note that our mailstore is not 17,179,869,184.0 GB in size.
  14. I'm seeing the same issue...after turning off circular logging on Exchange Server 2003 and rebooting, the Retrospect backup job says: Trouble reading files, error -3714 (some log or patch files are missing)
  15. But I'm telling you that I am backing up a Mac OS X Server, as a client, over the network, using the workgroup version of Retrospect 5.0, which is running on a Mac OS 9 host. It's working, but apparently it's not supposed to?