Jump to content

jelockwood

Members
  • Posts

    17
  • Joined

  • Last visited

  • Days Won

    1

jelockwood last won the day on October 18 2016

jelockwood had the most liked content!

jelockwood's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. If I am understanding your request correctly you want to be able to turn on an already installed Mac Retrospect Client. For the benefit of everyone I have encountered a similar need when pushing out to all our Macs an updated version of the Retrospect Client software. If you manually run the newer client installer on a Mac which already has an older version installed and turned on then normally after the update has completed it will auto start the newly updated version. However I was finding that when updating via Munki that it failed to start although it would auto start after a reboot, I therefore have found a command line means to do this and hopefully it will work for you. Munki would I feel be doing a similar job to JAMF in this case. I run the following as a post-install script for Munki. #!/bin/sh launchctl load /Library/LaunchDaemons/com.retrospect.retroclient.plist exit If anyone needs to, the reverse i.e. turning 'off' the Retrospect Client would be as follows. #!/bin/sh launchctl unload /Library/LaunchDaemons/com.retrospect.retroclient.plist exit
  2. The Retrospect Client for Mac installer does - at least when manually run correctly install the client and the client software itself i.e. the System PreferencePane does have its own correct version reported in its own plist at /Library/PreferencePanes/Retrospect Client.prefPane/Contents/Info.plist Unfortunately though the actual installer pkg file itself keeps being issued with the same version 1.0 in the pkg. This causes it to generate a receipt file also marked as version 1.0. The reason this is a problem is that enterprise software deployment/patch management solutions typically use the receipt file version number to determine if the currently installed version is older or newer than an updated version, for example Munki. As a result Munki will think the currently installed version is 1.0 and the version of the 'new' client is also 1.0 and therefore nothing needs to be installed as an update. I have reported this previously to Retrospect way back in March 2017 when version 14.0 was released and pointed out to them that version 14.0, 13.5 and 13.0 at least had this bug. They responded that this would be addressed in the next version which turned out to be 14.1 (it was not), I reminded them and was told again that it would be fixed in the next version i.e. 14.5 and sadly once again this issue has not been fixed. This would be absolutely trivial to fix, all they need to do is set the version string of the installer pkg to match the version of the client so it becomes 14.5.0.146 instead of 1.0. Sadly this is not by any means the first time Retrospect have repeatedly failed to address a bug - even if I will agree it is not in this case a critical bug. However since it is so simple to fix it is very disappointing it has repeatedly not been. Note: I have only myself encountered this with Munki but Munki is very widely used and I suspect other similar enterprise tools like JAMF or FileWave might also be affected as they also tend to look at package receipts. For what its worth my now long outstanding ticket for this issue is number #53902 they have so far failed to respond to my latest update.
  3. Retrospect ever since version 8 and still all the way to version 13.5 i.e. the very latest has been utterly insane regarding the amount of CPU power it uses. Retrospect is not a rendering program, it is not trying to calculate million digit prime numbers, it is a poxy backup program!!! There is no way it should need such massive amounts of CPU power, other brands of backup program do not. Previously Retrospect have come up with the absurd response that they are 'reserving' CPU i.e. grabbing 100% of a single core whether they need it or not. This is not how programs work, CPU usage is not like memory usage, yes for memory you do often need to pre-allocate a block of RAM but for CPU you use it or you do not use it, you do not allocate it regardless. Note: I have previously turned off every possible option like software compression, encryption, de-duplication, etc. etc. which made no difference. Now today whilst I am still very disappointed by Retrospect's continuing pathetic CPU utilisation problem I am reporting a new problem which appears to be a direct result of Retrospect being so bad with regards to CPU usage. We recently upgraded one of our servers to Sierra 10.12.3 from a previous generation of OS X. The Mac is the same model using the same drives with the same files on the same external data drive as before being upgraded, Retrospect has correctly spotted the files are the same so is not doing a backup of all files only the changed ones. One would expect the backup to take a similar amount of time as before the client i.e. the Mac server was upgraded. In fact technically speaking it seems the backup is taking a similar amount of time but what is taking hours and hours longer is the post-backup cataloging and snapshot making tasks. We have had a look at the Console logs on this Mac server and found that there are entries like the following Date/Time: 2017-03-01 08:10:39 +0000 OS Version: Mac OS X 10.12.3 (Build 16D32) Architecture: x86_64 Report Version: 19 Command: RetrospectInstantScan Path: /Library/Application Support/Retrospect/RetrospectInstantScan.bundle/Contents/MacOS/RetrospectInstantScan Version: 13.5.0 (173) (13.5.0.173) Parent: launchd [1] PID: 25918 Event: cpu usage CPU: 90s cpu time over 114 seconds (79% cpu average), exceeding limit of 50% cpu over 180 seconds Duration: 114.21s Steps: 130 Hardware model: Macmini7,1 Active cpus: 4 Fan speed: 1794 rpm This is showing that Sierra has spotted excessive CPU usage by RetrospectInstantScan and the implication is that when this happens Sierra throttles the CPU usage of this process which would slow it down and then slow down the Retrospect backup. Note: We also saw a similar message for the RetroClient process as below Date/Time: 2017-02-26 13:11:08 +0000 OS Version: Mac OS X 10.12.3 (Build 16D32) Architecture: x86_64 Report Version: 19 Command: retroclient Path: /Library/PreferencePanes/Retrospect Client.prefPane/Contents/MacOS/retroclient Version: ??? (???) Parent: launchd [1] PID: 62 Event: cpu usage CPU: 90s cpu time over 123 seconds (73% cpu average), exceeding limit of 50% cpu over 180 seconds Duration: 123.28s Steps: 107 Hardware model: Macmini7,1 Active cpus: 4 Fan speed: 1794 rpm Although this one surprisingly is not logged for every day. These logs are located in /Library/Logs/DiagnosticReports/ Note: These particular logs are not created on a virtually identical El Capitan server and those El Capitan servers have not exhibited this new problem although as mentioned like all Macs running Retrospect server or client use excessive CPU power all the time a Retrospect task is active. It seems it is possible to disable Sierra's CPU throttling mechanism but that this is not an easy process. See http://apple.stackexchange.com/questions/254143/how-do-i-disable-configure-macos-sierras-auto-throttling-of-the-cpu-for-process Once again I stress the problem is Retrospect's long time and still present pathetically poor CPU utilisation. (We will ignore the fact Retrospect is also almost completely incapable of using multiple CPU cores for a single backup script even though logically many tasks could be overlapped or distributed e.g. compression, encryption, cataloging.)
  4. The default time window for Proactive backup scripts is 00:00 to 00:00 i.e. midnight to midnight the next day and Retrospect server specifically treats this as the beginning of one day to the beginning of the next day. Unfortunately the same logic does not seem to apply to custom user defined time windows. For example if one wanted to do midday to midday i.e. 12:00 to 12:00 then Retrospect rejects this and will not accept it at all and therefore will not treat it as covering a 24 hour period. This is not only I feel a bug it is rather annoying since despite what Retrospect themselves may think I am not going to be coming in to the office to change over the backup media at midnight each day. As a result if typically one did change over the media at midday with the standard 00:00 to 00:00 window then actually you will only get backups happening for half the day at most.
  5. After you add a new source that is a Mac running the Retrospect client you can configure whether the source is used to backup all drives on the source, or selected drives, or just the boot drive. Unfortunately this has a tendency to go wrong - frequently. As a result it then typically backs up drives you do not want backing up with the then result that the backup medium gets full up and therefore often needs to be recycled and therefore unavoidably losing all your previous incremental backups. This then can mean the next backup takes a correspondingly longer amount of time and in the worst case can take several days or cycles to catch up. Examples of events that can cause this are - Renaming a drive on the source Plugging an additional drive in to the source Initially having a source configured to all drives which at that time might have been desired but later changing it to selected drives and Retrospect not obeying this change even though the Server console shows it is correctly configured Retrospect for some unknown reason showing two or more duplicate drives when these do not exist In theory I believe using the 'Refresh' option in Retrospect in Sources should tell Retrospect Server to update a source and the list of drives on the source and one would expect this to i) remove no longer present drives, ii) to add new drives, and iii) to rename drives listed as appropriate. Sadly in all or the overwhelming number of times I have tried this Refresh command it has failed to update the drive list. Since the Refresh command does not help, the only workaround I have found involves removing the source, re-adding the source, then re-adding the source back to the script. As mentioned the most annoying issue is it causing backup media to become full and needing to be recycled. This is happening with Retrospect Server and Client 13.5.
  6. Thank you for this, it does at least seem to explain things. I am not sure I found the same KB article you are referring to so if you have a link to it that would be appreciated. I have not seen any similar options in the Mac version but I would want the security changes backed up as these would of course need to be available to be restored. I am currently recycling the affected backups.
  7. Retrospect is supposed to be able to do deduplication and in fact has had this feature since before that term was invented. It can compare a file backed up by a single server against previous backups - a simple incremental comparison, and it can compare the file backed up by multiple servers and in the same location on those servers, and it can compare the file in any location on multiple servers and if identical only needs to store a single copy. In Retrospect 8 or higher this option is located in 'Options' for a backup script under the sub-heading Matching under the heading Backup. I have my script configured to Match source file agains media set, to Don't add duplicate files to the Media set, and not ticked to Match only in the same location/path. There is another option in the parent level of Backup which says Block level incremental backup. This to me implies that data deduplication should look at each block of the file and only backup blocks that are changed. This would for example be particularly useful for backing up files like a virtual machine disk image which are large files but most of the content will not change. My problem is that I recently applied an ACL permissions change to a lot of files. This change would not actually change the content of the file but would change the permissions of the file and might change the modification date as well. I therefore did not expect this to result in a lot of extra storage space being used for the backup. However when the backup did run it seems to be doing a back of the full file again because the amount of space used jumped significantly far more than a normal incremental backup. So it seems that something as minor as a file permission change is resulting in the data deduplication being useless. Has anyone else seen this sort of problem? Any suggestions? Should this be filed as a bug? Note: I am running Retrospect 13.5.0 (173) on El Capitan 10.11.6
  8. I see Mayoff has confirmed it has not been activated as an update yet, with regards to your answer as I pointed out my version 13 Multi-Server came bundled with Annual Support and Maintenance meaning even if it had been a chargeable upgrade it still should have shown up.
  9. I currently have Retrospect 13.0.1.106 installed on a Mac running El Capitan 10.11.6. This is working fine. However I today received an email notifying me of the availability of Retrospect 13.5.0.173, I therefore did the logical thing and told Retrospect to 'Check for Updates'. It reports there are no updates available. I have a properly licensed and registered Multi-Server copy which came bundled with a years Annual Support & Maintenance, so it should recognise that I am entitled to this update. I can see the updates are available to manually download from the Retrospect website. Is the Check for Updates function broken? It does not give an error merely says that there are no available updates. Have Retrospect not yet released this update via the Check for Updates mechanism?
  10. As an additional comment, if you are backing up an encrypted source then as I previously explained this typically means Retrospect is seeing the unencrypted contents of the encrypted volume. This in turn normally means the backup created by Retrospect will not be encrypted. Since obviously it was considered necessary to encrypt the original source you really, really must consider telling Retrospect to encrypt its backup mediaset. You cannot convert an existing Retrospect mediaset to/from being encrypted so you either need to remember to make this choice at the beginning or create a completely new mediaset. Remember there is no point encrypting the original source and then leaving a backup copy which is not encrypted and which can therefore be exploited by data thieves.
  11. Ok, I deleted and created a fresh new unencrypted media set. So now there is no compression, no encryption, no verification, client fast scan is turned off as suggested, deduplication is as much as possible turned off. Even network client traffic encryption is turned off. I am now running an initial backup and it (RetrospectEngine) is once again taking as near as damn it 100% CPU. This echoes my experience back with Retrospect 8. Obviously being an initial backup there is no grooming happening. "Something is wrong in the state of Denmark." Shakespeare's Hamlet - Hamlet (1.4), Marcellus to Horatio
  12. There are three main types of FileVault encrypted volume, your boot volume, an external drive and an encrypted network Time Machine backup. You can only backup the boot volume if the Mac is booted and a FileVault authorised user has unlocked/logged in. (Duh!) This also means the operating system gets loaded and so does the Retrospect client. Then the Retrospect Engine can talk to the Retrospect client and can do a file by file backup and will not be affected by FileVault encryption. If however you want to backup a FileVault encrypted external drive then this first has to be mounted. Then once again Retrospect will be able to see its contents and back them up. For an encrypted network Time Machine backup this is encrypted SparseBundle disk image. As already discussed this cannot be backed up or more importantly cannot be successfully restored. Hypothetically this encrypted sparse bundle disk image could be manually mounted and then once again the contents backed up via Retrospect. Merely entering Time Machine user interface would not mount it in a way that is likely to work with Retrospect. You would have to locate and double-click on the sparsebundle to trigger a mount request visible to the Finder.
  13. It is disappointing if Retrospect itself does not allow ejecting hard disk backup media despite what the GUI implies, but a possible workaround would be to write a post backup script which then ejects the drive for you. You would probably have to use a fairly simple disk naming scheme or your script might become excessively complex.
  14. 1) It is the RetrospectEngine process 2) It is still in the middle of the initial backup - remember I recycled the media to remove all traces of previous use of compression, I did find the Instant Scan option for the source network client and it was enabled, I have turned it off, it has made no difference yet but as mentioned it is already in the middle of doing a backup. 3) I currently have it set to NO verification 4) I would have to completely destroy and recreate the mediaset to switch to AES256 but both AES128 and AES256 should be able to be done via the Intel CPU routines and therefore neither should cause this level of CPU utilisation. I strongly believe Retrospect is still doing AES purely in software which has not been necessary for years. Using FileVault encryption again as a comparison I believe Apple say that with Intel routines i.e. running on a suitable Mac then FileVault encryption only adds a 5% CPU overhead, whereas doing the same encryption on an older CPU without Intel routines to offload the work it would be about a 20% overhead - still a lot less than 100%.
  15. A further update. Upon reflection I wondered if the fact the initial backup having been compressed meant it was still having to do a lot of decompression to do file compares for subsequent incremental backups. I therefore have recycled the backup i.e. wiped it. It is now running the equivalent of a first initial backup again. I can see that currently with compression turned off but encryption still turned on that the CPU utilisation of RetrospectEngine is fluctuating between 70 and 95%. So it looks like turning off compression has made a very small improvement. Since no matter what Retrospect might think these days it is essential to use encryption to secure backups and since as I pointed out AES encryption should be possible with hardware assistance via the i7 CPU I would still say the performance of Retrospect is appallingly bad. See https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni When Retrospect 8 was launched and obviously more so for earlier versions Intel i series chips did not exist. So it would be reasonable to expect that originally AES encryption was having to be done purely in software. This of course has not been true for years, it would seem Retrospect have failed to update their software to implement even this basic and obvious improvement.
×
×
  • Create New...