Jump to content

jel

Members
  • Content count

    79
  • Joined

  • Last visited

Community Reputation

1 Neutral

About jel

  • Rank
    Occasional Forum Poster
  1. 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?
  2. 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.
  3. 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.
  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. 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.
  6. 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.
  7. 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).
  8. 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.
  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).
×