KingMongo

Ah, I see; thanks for the info! It actually makes sense, now that I think about it, that standard windows/dos naming conventions would note be included in the definition of Universal on an application developed for the Mac.

I'm trying to exclude a file which Retrospect continually gacks on--it's about 3.5GB in size. I can't seem to do it. I've tried excluding the path, the containing folder, pattens with the filename, file names containing the file name, files of that size, etc, etc, etc. Is there some different behavior when doing an Immediate Backup, as opposed to a Scripted Backup? I'm using the exact same selector, and have been testing its efficacy by using the Immediate Backup's Preview function, I just can't get that *E*U#(U file to *not* be marked during the preview!!

Yes, that's correct. If it doesn't get backed up during the day, then the "Archive" bit does not get reset, and the next time Retrospect looks at the file to see if it should be backed up, it knows what to do. Good luck! Retrospect can be...uh...challenging to work with...

Hello, Two things: first, Retrospect's support is pretty weak. I've been using Retrospect since BEFORE they charged for support, and I quit calling them long before they started charging, because the only thing I ever heard from them was "hmmm...have you tried adding more RAM" and "hmmm...sounds like SCSI communication problems to me." Bah. Uh, in your case, if you do a Restore, you're not going to do a normal Restore; you're going to Restore an Entire Disk, which does *not* restore to a folder, like a normal restore, but, well, writes over the destination. So, in order to do a restore, you need a working operating system, networking, and the Retrospect client installed on the destination for the restore. You'll connect to the client via the server, Restore the Disk, then restart the destination computer, and that's it. You may end up having to reinstall one or two things, stuff that wasn't backed up properly or whatever, but otherwise, it works pretty well.

"Server" and "client" in your situation are relative; if you install Retrospect Server on your workstation, it's the "server;" if you then back up another computer, from yours, then that other one is a "client." So, the short answer is yes, absolutely. There is a qualifier, however. If you do daytime backups of the Snap server while you & your colleagues are using it, any files that you have opened, won't get backed up. And, any files that you open during the backup, won't compare properly, and won't get backed up. So, daytime backups sort of suck. You can always give it a go, then watch the logs & see what files are in use during the day and not getting backed up, then decide what to do at that point.

My opinion is that it's not productive to decide how many tapes you want to use for your backup ahead of time. Decide what kind of schedule you want, then see how many tapes that ends up using, is my advice. How many Backup Sets do you want? I have two Weekly sets, a Weekly A and a Weekly B, and they alternate.

You can send $95.00 to... Glad it worked!

Hi, Have you checked the firmware version on your tape drive(s)? Also, the version of Retrospect & its drivers could be an issue. Retrospect's KnowledgeBase points to SCSI communication problems as being the golden fleece of all fix-its, but I would start with firmware & drivers.

We had a similar problem with the backups of our mail server, which has hundreds of thousands of tiny 1k files (or 4k, I forget the cluster size). Anyway, our solution was to use the command-line version of WinZIP and run batch files to compress all of those files into a single .ZIP file, which has worked pretty well. It's really the file headers that slow down the I/O process of the backup, and Retrospect gets pretty agitated when communication slows down, and gacks with the ubiquitous -519 error. That's a solution that might work for you; it reduces your thousands of file headers down to a more manageable "one."

Hello, I've got a single archive file which is slightly less than 2GB in size (1.95GB) which Retrospect continually hangs on. This has *never* happened before, but happened first on 02/06/02, then again on 02/08/02--at this time, I need this file to be backed up (it's an archive copy of our company email, which is written to on a daily basis as we add mail). I suppose that I could break the file in half, but I don't *want* to. This is Windows 2000 Server, on NTFS; there should not be a ceiling on the size of my file (certainly not a ceiling that I should be approaching, yet). Has anyone else encountered this problem, or, better yet, encountered a solution or workaround? Greatly appreciate any help.

I don't really have an answer for you, but I like troubleshooting Any chance that they show up in the detail of Sessions, under Backup Sets?? This is a downside to Retrospect's Log & Reports--a little weak on detail. Yes, it's a shame about the T/S policy; Veritas (Backup Exec) has the same policy, but their KnowledgeBase is more robust; of course, their product also costs about a dumptruck-size load of cash. G/L!

To your first question: the short answer is no. The long answer is that the intent of the Sessions is to have an unbroken record of activity in that Backup Set. the Sessions of a Backup Set. When you're doing a restore, and your situation may be different, you usually don't *want* files from every session, but from a particular session. A restore of a file from every session would mean a copy of that file from every single time that it was ever backed up--that can be quite an imposing number. Granted, there are situations when it might be warranted. 2nd question: I know there is, but I'm not sure of the precise option(s) to select to make that happen; it doesn't happen if you restore a full disk, or to original location, I believe.

Yah, you won't get any compression on image files, or most media files, for that matter.

Hello, Just to clarify your original post, you performed three separate jobs? And they all show up in the log, but not in the report, right? When you scheduled the Immediate Backups, did you see them initiate? In the log, do the quantities of data that were copied look right? Last, the scripted event should not interfere with an Immediate Backup; it should queue up behind whatever event is running. Operative word=should. Unfortunately, you can't ask Retrospect anymore, given that they just terminated their included tech support (part of the reason we chose Dantz's product) for a by-incident program. Feh.