Jump to content

ernst_mulder

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

3 Neutral

About ernst_mulder

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
    Male
  1. Rebooting did not help. What did seem to have helped is a re-install of the Retrospect Engine (by installing the package created from Retrospect -> Preferences > Console -> Export Server installer...) Today all my scheduled scripts have run automatically. Could it be that the upgrade to Mavericks broke the scheduling part of the Retrospect Server engine? So, Retrospect users upgrading to Mavericks, please check your schedules' "Next Activity" dates.
  2. I'm encountering an annoying issue since upgrading to Mavericks and Retrospect 10.5. I'm not sure which of these is the culprit but I suspect it's the upgrade to Mavericks. My scheduled backups won't run anymore. Except for Proactive Backups which run fine. After that the "Next backup" will show the date when the backup last ran and not proceed to the next scheduled backup date. See attached screenshot. Removing and re-creating the schedule does not help. Pausing and resuming the scheduled scripts does not help either. I now have to manually start these scripts daily. Ernst
  3. Think I found the cause: It seems to happen to the contents of folders that have been MOVED from one subfolder to another on the source on scripts backing up to a disk based Media Set. I haven't (yet) found the same issue on tape-based scripts. Apparently Retrospect concludes it already has backed up those files (which is true) but doesn't show them in the correct folder (on its new location) during a restore (and nether while browsing the content of the backup)! Checking "Match only files in the same location/path" forces Retrospect to backup the content of moved folders again. Seems a data loss bug to me.
  4. Last night all our backup scripts re-ran with "Match only files in the same location/path" switched on on all scripts. One of my (remote) client's sources (a single server volume backed up to a single disk based grooming media set reserved specifically for this client) had to back up >40GB extra, it's actually still running. I haven't checked all our backups to determine which files were now backed up that weren't previously but I have checked a few and it looks like it always concerns small files (older Microsoft Office documents and such). Files that certainly weren't backed up previously and certainly didn't have exact duplicates elsewhere on the source (yes I checked). Next to those a lot of system files were backed up, which is logical because that's exactly the kind of files that would be excluded by not selecting "Match only files in the same location/path". Am I misunderstanding Retrospect's (default) matching options causing our backups to be incomplete (which would be bad in any case considering that it's a default setting) or is this a bug? I am currently checking all my backups and so far it seems that this issue only occurs where the destination is a disk based Media Set. So far I haven't found any tape based backups that included previously skipped files. I will report when I know more.
  5. Hello, After doing a test-restore of one of my Retrospect backup Scripts I found out not all files on a source volume were backed up. The Script backs up all files of a network Client's disk as a Source to a disk based Media Set with grooming. The Client's disk mostly has very small files, Office documents and such. Instant Scan is off. There was no common denominator that I could find in the files missing on the disk based Media Set. After restoring the disk some folders were completely empty, others only had a few files where the source disk had many. The backup Script has default settings except for the option "Use attribute modification date when matching" which is off. The selected rule is "All Files". After playing with the settings a bit I found out that the missing files would be included in the backup only after I selected the option "Match only files in the same location/path" (which is off by default and should be off according to the manual). It seems like Retrospect somehow concludes the files are already backed up (which they aren't) or that they are identical to other files part of the Media Set (which they aren't, these are unique files). I would like to know how this could happen? For now my new policy is to always select "Match only files in the same location/path" in all of my scripts. Had there been an emergency I would not have been able to restore all data in this case, which I find very scary. Retrospect 10.5 Mac.
  6. ernst_mulder

    Snap shot ending up with 0 files

    Lennart, This script was fine while I was still running verson 8.2. Also the script was fine last week. No changes. Retrospect actually does copy 250GB of data off the server but somehow fails to register what it has copied. After the backup the File media set grows 250GB but the backup shows that 0 files were copied.
  7. Hello, In my Retrospect 10.0.1.105 test environment the following issue props up: A successful backup ends with a snapshot containing zero files. The setup Backup source: Mac OS X 10.6.8 (Mail)Server running client 6.3.029 Backup machine: Mac OS X 10.8.2 running Retrospect 10.0.1.105 The backup script is set up to make incremental backups to a File media set. The backup seems to run fine but after completion Retrospect claims the snapshot contains 0 files. http://choke.grafisis.nl/zerofiles.png The File media set has the appropriate size but when the next backup is done zero files match and the source is completely backed up again. After a couple of runs the 1TB limit for the File media set is reached. What could be the issue here? I've already done a recycle and a repair on the File media set which didn't help. No errors in Retrospect's log. Ernst Mulder GrafiSIS & AdvieSIS BV
  8. ernst_mulder

    Retrospect 8.2 is dangerous

    Today it happened - again- right under my nose. I was editing a script on server A. Suddenly some of the scripts of server B were also visible between server A's scripts. After quitting the console app and starting it again one of the scripts of server B was modified, schedule gone, selector gone. I'm sorry but this is not a working product.
  9. ernst_mulder

    Retrospect 8.2 is dangerous

    Re: The user interface is dangerous Here is an example where Retrospect mixing up scripts, showing the scripts of one backup server with another: Wrong: http://mulder-thuis.nl/retrospect/screenshot4.png (the scripts mentioning "bobine" are actually from the backup server called "bondi") Right (after stopping and starting the console app): http://mulder-thuis.nl/retrospect/screenshot5.png I am wondering if this phenomenon can be the reason why settings of scripts keep changing themselves.
  10. Hello. I have a couple of clients running Retrospect 8.2. We are experiencing quite a number of issues and I would like to have a solution. Retrospect 8.2 is supposed to keep customers safe, instead it's an almost guaranteed path towards data loss. Not all of my customers have an ASM by the way. Scripts keep forgetting their settings. For instance: Today one of our customer's scripts forgot which Media Sets to backup to. Last Friday everything was fine, this morning they were not selected anymore. When checking the rest of the scripts various settings were gone as well, for instance "Use attribute modification date when matching" was selected again. After a power surge, where the machine running a Retrospect server was affected, we had to recover one of the disks used as a Media Set using DiskWarrior. This led Retrospect to suddenly select AN ENTIRELY DIFFERENT drive as its destination in the script that used to use the recovered drive. If I hadn't caught this that drive would have been overwritten when running the script. Retrospect can't keep itself running. For instance: The Retrospect server part crashes and is not automatically rebooted. The server part is started using a launchd plist but KeepAlive is not used. Retrospect Clients do not time-out their connection. This happens for instance when backing up over the internet. If a connection is lost the Retrospect Client is still "in use" and does never recover. Manual intervention is necessary to restart the Retrospect Client. The user interface is dangerous. For instance: On a system where the Retrospect console application is installed anyone can change scripts and settings. Script settings should be password protected or at least acknowledged and the console application should be password protected. When (This one really bugs me!) controlling multiple backup setups remotely using the Retrospect console application, the application loses track of what settings belongs to which server address. Scripts from one server are suddenly visible on another server. Media sets from one situation are suddenly visible at another server. This is really scary, and may even be the cause of other issues we're experiencing. I would like to monitor the backup status of my clients, so I have multiple servers configured in a Retrospect console application on my workstation. The user interface has scary warning messages, some of which are not even correct. For instance: when selecting "Overwrite entire volume" the warning "Warning: Destination will be erased before copying." is given, which is not true. Also when running that script the warning "Are you sure you want to erase the entire source before copying?" is given at which point most of my users bail out because they have no idea that the "Source" in this case is actually the "Destination", just as in the first warning.
  11. > I wanted to publicly thank Ernst Mulder for being the one to identify the cause of this problem. > It was very helpful since we were unable to reproduce the issue at EMC until he posted his findings. Wow, thanks :-) I couldn't have done it without the info others provided on this forum of course! Thanks to everybody looking into this problem. Ernst Mulder
  12. You can download one of my troublesome retropds.log's here: http://os36.grafisis.nl/dantz/ Ernst Mulder GrafiSIS & AdvieSIS BV --- Mail to forums@dantz.com bounces with the following result: This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. CN=Robin Mayoff,OU=TS,OU=WC,DC=dantz,DC=com
  13. More info: Simply removing /var/log/retropds.log on the client machine even with the client running does the trick. I've got all our clients up and running again without restarting anything (removed the troublesome logfiles using ssh) and without editing any scripts. Does this mean however that the problem will return when that specific log file grows again in time? Ernst Mulder GrafiSIS & AdvieSIS BV
  14. YES!! I think I might have found the real cause (more testing underway). Following up on my previous post, I went to another problematic machine. I did the following: 1) sudo killall pitond on client 2) sudo rm /var/log/retropds.log (which was 109MB) 3) started the retrospect client problem solved, the server immediately connected again, no need even to forget/reconnect. So please, testers, test with big /var/log/retropds.log files (I could send you one of mine if you want). Ernst Mulder GrafiSIS & AdvieSIS BV
  15. What does the client uninstall do exactly? When I do the following: 1) forget client on backup machine 2) sudo killall pitond on client 3) sudo rm /Library/Preferences/retroclient.state on client 4) sudo rm -r /Applications/Retrospect\ Client.app 5) reinstall client 6) sudo killall pitond, unmount installer image, start client* 7) reconnect to the client on the backup machine the problem persisis. When I do the following: 1) forget client on backup machine 2) sudo killall pitond on client 3) uninstall the client using the client installer 4) immediately reinstall the client 5) sudo killall pitond, unmount installer image, start client* 6) reconnect to the client on the backup machine the problem is solved. So , what's thate xtra thing the uninstaller does? I did notice it clears the logs matching /var/log/retro* some of which were quite big, my retropds.log for instance was 241MB. Something worthwhile to look at? *The retrospect client installer STILL auto-launches pitond from the installer disk image, can this please be solved one day? Instead of restarting the client Mac I kill the pitond after installation and start the client again which has essentially the same effect. Ernst Mulder GrafiSIS & AdvieSIS BV
×