Jump to content

Tramper

Members
  • Content count

    24
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tramper

  • Rank
    Occasional Forum Poster
  1. There is a bug in preview whereby if you have a preview open, change the selectors in the script, then allow the preview to update while the total for the amount being stored (in Gb) is correctly updated, the "directory" listing indicating what is being backed up or not **IS NOT UPDATED**. You *must* close the preview, then re-open it to force it to update it properly. I'm very pissed off with this as for ages I *swore* that none of the pathname selections work. Further trials show that you can toggle the arrow on the Macintosh HD folder closed then open again to force the listing to be updated properly. Of course EMC hasn't updated Retrospect on the Mac in how long...?, so we're not going to see a bug-fix for this, so this is just a head's up to save others the crazy waste of time I've experienced.
  2. Thanks -- 1. I tried putting the name of my subvolume into the Name (Volume) option of the include/exclude options and it didn't recognise it. I'll try again. BTW, I'm not talking about selecting an entire volume, but excluding a subvolume that is a subset of the volume I'm trying to back up using the include/exclude options within Backup>Selecting. 2. I've managed to--eventually!--figure this out. Personally, while the set up the exists suits the implementation, I'd prefer to see Retrospect always deal with the empty folders, it'd be less confusing for users (IMO). Likewise is confusing how Preview shows empty folders as unmarked, when in fact they are recorded in a sense (in the snapshot as you say). 3. This is my fault in a sense. *If* I'm reading things right there are basically two forms of restores, either to completely replace an existing folder hierarchy or to restore to a new folder. What there isn't is a restore into an existing hierarchy, but noting what is there by following a set of rules as what to replace, etc. This is more easily visualised in a mirror/synchronisation operation, where content on both sides are changing and you are trying to map the changes in one (the source) to the other (the destination), but you want to be careful of file name and type conflicts. For example, if on the destination you decided to move a folder hierarchy to another position, but leave an alias to it in its place with the same name, you may not want the new alias in the source replaced with the folder hierarchy on the source. At the least you'd want a warning of a name+type conflict (same name, different type). Some backup/synchronisation programs for example refuse to replace a folder with a file or alias for example, as in principle the user could be losing data and instead flag a warning. (Phew, hope that's clearer, long paragraph...!) I get the impression this isn't possible in Retrospect, that all you can do is restore to a new folder, then resolve this issue yourself. My currently feeling is that I may knock up a script to do this.
  3. I am returning to Retrospect after using other tools for a while. I can't seem to be able to do some things at all, not under "straight-forward" use anyway. So... how do I: 1. Select defined subvolumes under 'Selecting' ? (This seems a much clearer alternative to unmarking the relevant folders in Preview, IMO.) Using 'Volumes' is only selecting the system disk volumes, not the subvolumes I've defined in Retrospect. 2. How do I get Retrospect to back up empty folders ? This is essential really and must be possible somehow... 3. Where are the options to govern responses to file/folder/alias/link name conflicts ? (i.e. Where the source and destination have the same name but different "file" types.) Again essential, but I can't seem to find it. I hope I can get a quicker response than my previous post! ;-)
  4. Not exactly a high-volume forum!! ;-) More seriously, upgrading to OS X 10.4.7 seems to have cleared this problem. Strictly speaking I may be speaking too soon as I need to do more testing but at least for the first time a decent sized backup as gone through with a a few hundred-odd error messages. For those who do have external USB devices, it would seem that you might have to avoid OS X 10.4.6 -- ?
  5. Forgot to add, I'm doing a 'File' backup. The backup is big, 150Gb+. I haven't yet tried using a "Removable Disk" backup, which is another thing to explore; I can't imagine it'd make a difference, though.
  6. OS: 10.4.6 System: Dual G5/2.0GHz/4Gb RAM Retrospect 6.1.126 / driver access 1.0.107 / driver update 6.1.7.101 I've recently installed a 320 Gb SATA drive into a SATA/PATA external case accessed via USB (the case supports USB 2.0). Backups using Retrospect consistently report 'miscompare at data offset' and other errors (e.g. checksum errors, etc.). Backing up the exact same data to a different external Firewire drive on the same machine works just fine; no errors at all. This suggests one of these might be at fault: - Retrospect doesn't like USB on 10.4.6 - 10.4.6 doesn't "play fair" with USB drives - the brand-new Seagate drive is effectively DOA - the external USB <-> SATA case is somehow faulty I've tried using different USB ports on the machine, its not the particular port. I've tried jumpering the drives from 3Gbps to 1.5Gbps; no difference (in any event in either case, the transmission speed is limited to 480Mbps according to System Profiler). Any suggestions are welcome. Is anyone experiencing trouble with using Retrospect to external HDs over USB? I'm considering upgrading to OS 10.4.7 but I get reports of more trouble with external drives on 10.4.7, so... what do people here think?
  7. I've searched the compatibility database and can't find my device (see subject line); it is the Apple-installed device in my dual 2Gz G5 which is now several months old. Even if its not supported, surely all the Apple-installed drives would expect to be listed in the compatibility database? I see a bunch of DW-UnnA's (where nn is a two-digit number), but no DW-Q's. Yes, I know there is "Configure", but I'd welcome feedback before creating toasters! Been burnt (pun intended) once already...
  8. Bit of a long shot: have you tried disabling Spotlight before trying the backup?
  9. I have long suspected that the (many) problems Dantz has with compatibility, etc., come from choosing to use a very low-level approach to interacting with the drives. This makes the software very dependent on the exact drives and driver software. I'd like to think there are "higher level" and less device-dependent approaches to solve the problems that Dantz claim to need these low-level approaches and some of the posts here seem to indicate that there are. I would strongly urge Dantz revisit how their software interacts with drives (more accurately, drivers) and at least try provide "higher-level" options so that users can opt out of the current low-level approaches, even if there is some lose of fine granularity, as their is likely to be. Higher-level solutions might not be so much fun to the engineers, but... client's first? I also wonder if this approach stems from the heyday of the tape drive...? I haven't seen anything to indicate that other backup software for the Mac has these problems; I have this nagging suspicion that the reason is that they use fairly high-level approaches to interacting with the drives, letting the low-level software present worry about the finer details. I'm having to move off Dantz for reasons related those discussed in this thread: writing to DVDs doesn't seem to work (for Mac G5s at any rate) for reasons that sound very much like the elements here. I've waited more than long enough, so I just have to move on (practicalities and all that).
  10. Wim, Can you clarify if you mean "don't do it" for all backup software or just Retrospect. I think you mean the latter, right? I'm slowly doing something similar: phasing out Dantz, using external Firewire as my daily backup and some other software to backup to permanent media for my weekly backups. (Using a combination of local 'net mirroring and backups to CDs as parallel approach until I'm happy with the new scheme.) My guess about these issues is that Dantz' software does its work at such a low level that its forced to respond to even the slightest change in the devices or device drivers. Continuing assuming I'm right (!), in my somewhat ignorant opinion this might have been a practical approach in the heyday of tape backups 15+ years ago, but its clearly hopeless for modern CD/DVD drives. Software that leverages the existing system software to access the drives should avoid most of these problems as most of the other backup solutions for the Mac appear to do (although, to be fair, you lose some features like those based on packet writing [?]). Pity really as the Dantz software does work well for the devics they do support.
  11. Same here. Dual G5 2Ghz / Sony SuperDrive. This thread is over a week old: can someone from Dantz please state Dantz' position on this? Especially as other, older, threads are reporting related issues and no response from Dantz on these threads either... I'm under the impression that Retrospect (Desktop) can't see that a backup device is present. If you go to Configure>Devices, it claims there is no backup device, when there plainly is. Under older machines this has happened (to me) if the power for the device is off. So I tried ejecting the tray (the dual G5s have no external power button for the DVD drive, but ejecting the tray ought to power it up--?), then starting R. Same result. However, if you click on Device Status, the drive shows up as a Sony DVD device, so Retrospect *can* see it after all... or at least what the OS thinks is there. Also no luck starting R after mounting the DVD in Finder as a blank DVD (as the note under "no backup device" in Configure>Devices suggests). The above is true for both the 6.3.102 and 6.5.102 driver updates. Anyone--is this behaviour new to OSX 10.4.2 or new to the hardware?
  12. Could someone from Dantz please respnd to this. I'm a registered user. I've written to support via the web form several days ago (no reply so far) and posted a direct email this morning. I'd appreciate your help, thanks. I feel very uncomfortable working without backups and I can't see any way of getting around this other than deleting all Retrospect versions and their associated files in /Library, etc. (assuming I can locate them all), then installing a full (non upgrade) installation at extra expense to myself. Grant
  13. I am trying (badly!) to upgrade 5.0.238 to 6.x. I've installed a demo copy of 6.0. Used that to restore my applications (its a long story), then started 5.0.238 to try get the license code so I can upgrade. It opens, but had lost all info about preferences, license codes, etc. (in fact it asked to base the preferences on 4.3 which I haven't used in literally years.) So I try a few things. Now none of my copies of Retrospect will start. I guessing that this is some software protection issue. So: 1. I cannot do any backup at all. 2. Surely demo versions should work regardless of license issues in other versions? 3. I have written to customer support but they have not replied yet... hence my writing here. 4. Can anyone suggest a fix to this. ASAP. I don't like working without backups. 5. Its ironic that Retrospect recovered by Retrospect doesn't work :-) Probably something to do with having to separately recover some files, under /Library or whatnot, etc.
  14. Having written the lot below, I realise I'm assuming you're using OS X...! If you're not, disregard this. I haven't time to read the details of your plans (too busy), but have you considered: 1. Make two run documents from within Restrospect. 2. Write a little AppleScript which prompts the users, asking them to mount he appropriate drive, and then executes the correct run document. 3. Pop the AppleScripts into cron to have them started up as desired. Someone correct me if I'm wrong, but a run document would avoid the problem of needing to "see" the other drive. FWIW, if I reading (guessing!) right, your scheme is effectively a fortnightly backup scheme, which is a rather long time between backups.
×