Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by jel

  1. I used Retrospect from literally version 1.0 to ugh! version 8, I then gave up on it. I started off with TEAC data cassettes, moved to AIT tapes (various generations), briefly in comparison used LTO tapes, and then finally ended up using hard disks in a drive dock as these became a cheaper, bigger capacity and supposedly faster solution than tapes. I say supposedly because Retrospect became a sick joke in terms of performance. At the time I moved to version 8 I also moved from Retrospect 6 on a Dual Processor PowerMac G5 with 2GB of RAM and a SCSI card and using tapes, to a Mac Pro with octuple cores, 24GB of RAM, and eSATA connected drive docks with SATAIII disks. It was if anything slower. (The Mac Pro also had an eSATA PCI card supporting SATAIII, in theory this should have been far faster than FireWire 800 or SCSI.) (You will note I deliberately said 'moved to version 8' as it could hardly be described as an upgrade - ugh!) One of the big disappointments in version 8 was the claim it was supposed to be able to do multiple backups at the same time assuming you had multiple backup devices. I never got this to work. Remember I was using hard disks as the backup medium not tapes. The main purpose of this post is to ask if Retrospect 11 will allow backing up multiple clients to multiple hard disks, more specifically as an example if I have the multi-server version with no addins will it be able to backup ServerA to diskA, and ServerB to diskB at the same time. I am extremely wary about the idea of moving back to Retrospect, I have seen some reports from users suggesting version 11 is a big step forward compared to 8/9 and the new feature of block level incremental backups sounds very attractive. However the problem with Retrospect has never really been down to features but the fact that even with version 6 and certainly 8 & 9 it had a miserable level of performance and again with 8 & 9 a truly awful level of reliability. The reviews even the recent ones on MacUpdate do not inspire a great level of confidence.
  2. PS. In theory a single hard disk backup set being a hard disk is a device capable of supporting multiple simultaneous sessions. Therefore again in theory more than one client could be being backed up at the same time to the same hard disk. I suspect the answer is no but does anyone know if this is possible?
  3. Thanks that's good news. Would you say Retrospect 11 is able to handle backing up 1million+ files from a volume without problems? This is where Retrospect 6, 8 and 9 used to struggle when doing the 'cataloging' phase of this large amount of files. It would spend hours doing the cataloging and you could see that it was not writing to or reading from any disks. It seemed to be CPU bound as it was running 100% of a single CPU core - so it was also not multi-threaded when doing the cataloging. Unfortunately it would not at the same time do a pre-scan of the next server in the list so this tied things up badly. I would now have some server volumes with 3 or 4million+ files on. One is a mail server so no - splitting the files across more smaller volumes is not an option.
  4. Dantz/EMC/Roxio/Retrospect/whatevertheyarecalledtoday produce various addins for Retrospect to backup other makes of database. Considering their loooooooooong Mac history it is amazing and very disappointing they they do not write an equivalent addin to automate backing up FileMaker Server databases. Other than the script approach suggested by Pete another approach is to use the standard ability in FileMaker Server to do scheduled backups to another folder, and then tell Retrospect to only backup that folder and not the 'live' databases. On a related topic, the same issue will apply these days to PostgresSQL databases as used by Apple's Wiki and Profile Manager software, and - if you use it MySQL databases. Again these are extremely common types of database even in the Mac world let alone Linux world and it is again a major failing and oversight for Retrospect not to provide their own solutions for backing up such databases. Just noticed, while it might be a less common scenario, even those addins for backing up databases that Retrospect do have are kept only for the Windows version making the Mac version a second class product. This is inexcusable, if they designed it properly addins should be platform agnostic.
  5. EMC have now finally issued a user manual for Retrospect 8, but it is woefully lacking in detail and examples. I am specifically looking for help defining an exclusion filter rule to exclude a folder and all contained files and any subfolders. The Mac OS X (Unix) style path would be /private/var/db/swupd/ While I feel I could as per the only example, successfully define a rule to exclude a path 'containing' say swupd, I want to define a path beginning with the above path, something that according to the software should be possible. Unfortunately, Retrospect is still backing up the above folder so I obviously have not got it right yet. I rang Retrospect support, and they did not know the answer. Does anyone here, know the correct format to define a path beginning with xxx? Many thanks for any help.
  6. Retrospect has a great feature set. Even with the current crop of glitches, it is also reasonably reliable. It is just so slooooooow as to be considered 'cruel and unusual punishment'. I have considered BRU, but its support for using hard disks as a backup medium is effectively non-existant. A much lesser issue was that it unlike Retrospect and most other backup tools of equivalence does not do 'data-deduplication'. As I said Retrospect has the features, it just is getting so slow it would almost be as quick to manually type a load of unix CP commands in Terminal.
  7. I did say I was specifically trying to define a Mac path using "begins with". I did also say I was confident that I could get a path working using "contains" since the only type of example given is "contains". I am wanting to use the provided and supposedly working ability to define a path 'beginning' with something because I want to ensure only the desired folder gets matched. To use a hypothetical example, if I used a path 'containing' Library it could and would match - /Library /System/Library /Users/xxx/Library etc. Unfortunately a Mac path 'beginning' with /private/var/db/swupd does not work in that Retrospect is still backing it up, so clearly Retrospect is not using simple standard Mac paths.
  8. Just because your (still) using PowerPC machines, don't feel your being discriminated against. Even an octuple core Mac Pro with oodles of RAM, and backing up to eSATA hard disks via a 6Gbps capable PCI card no less, is just as slow. It literally is faster to watch paint dry than watch Retrospect running. Retrospect building a snapshot is particularly painfull to watch since there is no network activity, hardly any disk activity, and even taking in to account that Retrospect in general is incapable of using multiple CPU cores, it is (for hours) only using 1.4% of a single CPU core. I have already switched one company away from using Retrospect due to its truly pitiful speed. They now use SuperDuper and are deliriously happy. They with SuperDuper are still able to have a rotating set of backups (keeping most off-site).
  9. jel

    Verification: Yes or No?

    Thanks for the useful thread. Considering Retrospect 8 is sucktastically slow at all operations, I was considering switching off all verification to make it "less" slow, I could hardly describe it as speeding it up :angryred:
  10. jel

    Retro8 Log Analyser

    FileMaker 11 (now out) adds a new repeating import facility. Would this be useful for your database so it can automatically import new log data from Retrospect? (I have Retrospect 11.)
  11. Since the Retrospect manual is still missing, I am forced to ask what should be a obvious thing. How the bleep do you see what files are contained in a backup? This was very easy in Retrospect 6.1 and possible even when the media was not present. This serves two purposes - 1. It lets me confirm a particular file has been successfully backed up which might be uncertain if the backup did not 100% complete. 2. It lets me see if a filter to exclude some files is working. If the files to be excluded have been backed up then the filter obviously did not work. Related to this is that being able to see the contents of a backup and then mark files to be restored is a much better method than trying to find a file name via a search and tell Retrospect to restore it. The search method (as it appears 8.1 uses) means you might restore a lot more than you want, or might have a slightly wrong name and not restore anything at all. In the continued absence of a manual it seems from the pathetically inadequate getting started guide that Retrospect 8 is much, much worse than Retrospect 6.1 in this area. EDIT It turns out that the problem(s) were - i. The current Day Light Savings time bug ii. The fact that Retrospect spins it wheels for ages before displaying anything (if the above does not strike). I have now been able to confirm my filter did not work.
  12. The status messages in Retrospect are themselves very poor and do not give a good picture of what is going on, indeed initially with Retrospect 8, one thought it had simply locked up since 'nothing was visibly happening' for hours. However your argument is slightly flawed in that Retrospect is not a brand new product and therefore using brand new routines that still need optimising, it is version 8.1 and has been using the same cataloging design for over a decade and has been offering poor performance for many, many years. People have been complaining about this poor performance also for many years (mainly in relation to version 6 and 6.1) and I am sure I am not alone in having hoped that the supposedly completely re-written version 8 would have addressed this well known issue. As I said it has now reached the absurd situation that catalog processing operations take longer than the backup itself and increasingly make it almost impossible to do backups in a practical timescale. It can take more than 24 hours to do a set of backups, most of which Retrospect spends thinking (slowly)! I am not aware of any other backup software that takes longer over catalog related operations than the actual backing up. Note: I have used Retrospect for over 20 years.
  13. jel

    Show Engine Version?

    Doing a get info on /Library/Application Support/Retrospect/RetrospectEngine.bundle may well show the desired version number but is hardly a user friendly method or one that would occur to most people. I would agree that the logical place(s) for the engine version number to be shown are i) In the Retrospect System Preference Pane AND ii) In the Retrospect Console to show the version of the potentially remote engine you are controlling - remember you can potentially control multiple remote engines. As the Retrospect Console can show the version number of the various clients it is linked to this seems a logical extension.
  14. When a backup completes (that is really completes) but shows some files remaining, this is in my experience due to - a) Files being busy and unable to be accessed Files changing between scanning and attempting to be backed up c) Files being deleted between scanning and attempting to be backed up A large number of files potentially could change during a backup such as web-browser cache files, other temporary files, email messages (each is an individual file), and if you have it installed your anti-virus software might have updated it self during the backup. One of the standard Retrospect filters does try and automatically exclude some temporary files, but some applications are poorly written and stick the temporary files in non-standard locations (e.g Word). In your case the number of files is well within normal limits, but the total size is far more than I would expect unless you had been working on a large file (e.g. video, or disk image).
  15. I think there may be three main areas leading to a substantial difference in speed between Retrospect and BRU. 1. Retrospect has had a form of 'data deduplication' since well before that term was ever thought up. This inherently requires more time. Tolis have chosen not to implement this even though it is an increasingly popular feature of backup software. However the above is only a small portion of the total difference, since even if you turn it off Retrospect is still glacial in its speed. (Actually with global warming Glaciers have sped up more than Retrospect.) 2. Retrospect completely fails to take advantage of multiple CPUs or CPU cores, not just for a single task, some of which like scanning are inherently linear and not possible to share amongst CPUs but others could be, but it also fails to overlap independent steps (e.g. compressing one file/block while encrypting a different file/block, while storing another file/block, while updating the catalog, while scanning the next volume. I get the impression BRU is far better at this. 3. Frankly one also gets the impression that the Retrospect software is just slow (i.e. grossly inefficient), for example merely writing out the catalog (snapshot) takes aeons. With backup media continuing to get faster (both tape and disk), these days it is quite likely that the actual process of writing the backup takes less time than Retrospect spends pontificating over scanning and cataloging (individually let alone in total). I have spoken to Tolis and they don't seem likely to add data deduplication, but the other handicap they have of poor support for using hard disks as backup media is on their list. Using hard disks as media is something Retrospect has done well for a long time (if slowly ). Note: The 'grooming' feature of Time Machine seems far faster than Retrospect, and more reliable in that it (in Time Machine) successfully prevents disk full errors (the whole point of grooming).
  16. jel

    Snow Leopard Support

    If you're willing for the program to be Snow Leopard only you're going to be needing an Intel machine for that. PPC will always be slower, Grand Central Dispatch or not. My post was not clear, but I bought an 8-core Mac Pro with 10GB of RAM specifically to run Retrospect 8.1 compared to the previous Dual Processor PowerMac G4 887MHz with 2GB running Retrospect 6.1, in the foolish belief it would be a lot faster.
  17. jel

    Snow Leopard Support

    All the tasks I have tried in Retrospect 8.1 show it is CPU bound as the main performance constraint. The only realistic way this can be resolved is if Retrospect 8 makes some use of multi-threading. I say some since clearly it currently makes no use of this at all unless you count running more than one script/task at the same time. As one of the big changes in Snow Leopard is the inclusion of Grand Central Dispatch to make it 'easier' for developers to add multi-threading to their applications, is there any likelihood of this being done to a future Retrospect update? Personally I would be more than willing to accept Retrospect becoming Snow Leopard only if this meant the performance improved substantially. As things stand it is currently little better than Retrospect 6.1 on a PowerMac G4 in terms of speed
  18. Anything longer than 24 hours is a horror story. In my case I have about 4.6million files in the backup and about 6 incremental backups for about 12 sources. I am currently using the auto grooming option. It is now apparently doing another groom but like always in my case the Retro Engine stubbornly refuses to use more than about 100% CPU, i.e. apparently only one core.
  19. Thanks, that does appear to show it using more than one CPU core. For what it's worth, I discovered today after yesterdays backup finished (later than normal), that it had for the first time ever done some grooming. I had not expected it to do grooming until next week so I did not check the CPU activity, I will check it next time. Rather than the horror stories of 40+ hours I have seen here, it fortunately only took an extra 10 hours (approximately). What was unexpected was that it seemed to only do the grooming after the backup had finished. I would have expected it to do the grooming first and then the backup so as to first free up space for the new backup. The order it (apparently) does it does not seem logical since now it will not have enough space for the next backup despite grooming.
  20. Have Activity Viewer running at the same time Retrospect is doing its business. If the Retrospect process is only showing a maximum of about 100% CPU utilisation then this means it is not using more than the equivalent of one CPU core, 200% would be all of two cores. As (so far) Retrospect seems completely incapable of using more than one CPU core, effectively my Mac Pro is reduced to being a 'single core' 2.26GHz machine, rather than the 8-cores it actually has. I have mentioned this in another thread and did myself point out that some operations cannot due to their nature be shared amongst multiple CPU cores, but plenty could. This urgently needs fixing as we are not going to get a '10GHz' CPU any time soon. Such a major design handicap might have been forgivable or at least understandable in the old Retrospect 6, but in the supposedly totally new Retrospect 8 with its completely new engine that is supposed to be able to do multiple things at the same time and be a lot faster [hah!] it is inexcusable.
  21. Could people check to see if Retrospect 8 when grooming is using more than one processor core? So far I have never seen Retrospect 8 use more than the equivalent of one core, even when trying options like encryption, and software compression. This is a huge waste of an 8-core Mac Pro, I might as well have used a Mac mini. On my über Mac Pro the CPU utilisation remains so low that you can barely see it on the graph, even when Retrospect 8 is supposedly working flat out. (This is not a good thing.)
  22. Thank you for the reply, hearing that you are acknowledging the problem(s) is a reassurance. My suggestion that Retrospect could be (in one thread) building the snapshot (even at its current diabolically slow speed) while in another thread starting the scanning/backup of the next volume, would make a huge difference in overall performance, it could even halve the total time to backup. On my 8-core Mac Pro I have so far never seen the Retrospect Engine go above 100%, i.e. just using one core, so the computer could easily do both tasks at the same time. I am still concerned that the performance/CPU usage I am seeing suggests Retrospect is limited (possibly due to a single-threaded design) to using a single CPU/Core. PS. It would seem to make sense for you to change Retrospect so that status shows "Building Snapshot" instead of nothing (i.e. a Dash) this would at least indicate it has not died.
  23. I have only recently upgraded to Retrospect 8.1 from 6.1 so I am still trying to get a feel for how it behaves compared to the previous version. As I watch it right now, it has it appears 'finished' backing up the biggest server volume (5 of 12) which contains on this one volume about 784,000 files. It currently says remaining 140 files, but these I believe are the ones it has failed to do because they have been deleted between scanning and backing up. (So they are no longer really remaining.) At a guess what it is now doing is preparing the information about those 784,000 files it has backed up to write to the catalog, however it has been like this for a very long time (of course 6.1 was notorious for this as well). However with 6.1 at least it would have shown a message saying it was updating the catalog. Currently in 8.1 the status is blank (a minus symbol) so I cannot be sure exactly what if anything it is doing. CPU activity on this 8-core Mac Pro is practically nothing, and it has 10GB of RAM of which currently 5.88GB is free. Yet again, it appears not only is Retrospect failing to take advantage of all the processors, it is also failing to take advantage of all the extra RAM. I am very disappointed about the complete lack of performance improvement over Retrospect 6.1 running on a far, far less powerful PowerMac G4. With supposedly a completely new design (engine) and now running on a machine several orders of magnitude faster, why cannot it be scanning, backing up, and update the catalog of different machines it is/has backed up at the same time? Is there some hidden setting to get it to use multiple cores? Hmm, as in this case the problem seems to be the one Retrospect has suffered from for years and years (an exponential increase in the time it takes as the number of files on a volume to be backed up increases), maybe a trick will be to make a series of 'sub-volumes' (aka. Favourites) for the top level folders of this large volume, and then it will only need to consider a smaller amount at a time. Or will it merely be that this means the time it takes is equivalent to 2+2+2+2+2=10 instead of 1 big volume taking 10 and not result in an overall difference.
  24. I noticed EMC Insignia/Dantz have released an update to Retrospect for Mac to add Leopard compatibility. Firstly congratulations and thanks for the speed of doing so. As a reward you can climb up from the Eighth Circle of Hell. However I also notice that Retrospect 6.1.138 i) does not add any new features ii) is not Intel native iii) even the client is still not Intel native (it was not updated) Now I know EMC Insignia only recently got the final Leopard version themselves and needed that to begin testing with. However is there still any intention to produce a real fullblown upgrade for Retrospect for Mac or is this what we are now going to be stuck with for the next couple of years? In particular the fact that it is not a fullblown Leopard and Intel application means it is still limited to using just 2GB of memory and I increasingly find that in order for Retrospect to read the catalogues of disks during backup it will run out of memory and start thrashing virtual memory. A fullblown Leopard/Intel update would allow it to access 64bit memory addressing (i.e. LOTS of memory). This can save literally hours of time doing backups. If there is no major upgrade underway, then sadly I would have to consign you down to the Ninth and final Circle of Hell. The lack of a fullblown upgrade also of course translates in to a lack of upgrade revenue for EMC Insignia. I have not been able to buy an upgrade for Retrospect for years! It also makes the Retrospect maintenance program rather pointless (further lost revenue).
  25. Yes version 6.1 does run on Intel Mac Pros. I have successfully setup one with a FireWire AIT-2 tape drive and another with a SCSI AIT-4 tape drive (I used an Atto UL5D SCSI card). I have not used it with DVDs (too small) but I would be interested in using it with a double layer Blu-Ray burner (50GB) which it currently cannot do.