Jump to content

aesmith

Members
  • Content count

    42
  • Joined

  • Last visited

  • Days Won

    1

aesmith last won the day on May 4 2012

aesmith had the most liked content!

Community Reputation

4 Neutral

About aesmith

  • Rank
    Occasional forum poster

Profile Information

  • Gender
    Not Telling
  • Location
    Canada
  1. I have asked the question the other way around but is there any issue with clients running the newer 9.0 version but the Retrospect server being version 8.5?
  2. aesmith

    Reverting back to v8.5 from 9.0

    No I have all email notifications turned off.
  3. aesmith

    Reverting back to v8.5 from 9.0

    I am still trying to recover from the backup corruption that version 9.0 created. Seems to have something to do with the block level backup option. It seemed to work fine until I turned this on. I am going to wait until the bugs are worked out before I give this another try. Block level backup would have been great if it worked as a lot of the biggest parts of the backups in our location are PST files.
  4. aesmith

    V9 scheduled backup stalling

    Hmmm went back to version 8.5 and this particular client is still taking close to 10 hours to complete, mostly stuck at storing snapshot. + Normal backup using $[1]win2003$[2] at 3/26/2014 3:25 AM (Execution unit 3) To Backup Set $[01]$[*!20825,,14,+3]New Win2003$[02]... 3/26/2014 3:25:36 AM: Connected to $[*!20780,,14,+3]win2003 * Resolved container $[*!20780,,14,+3]win2003 to 2 volumes: $[*!20612,,14,+3]System (C:)$[3] on win2003$[4] $[*!20611,,14,+3]Data (E:)$[3] on win2003$[4] - 3/26/2014 3:25:29 AM: Copying $[*!20612,,14,+3]System (C:)$[3] on win2003$[4] Using Instant Scan 3/26/2014 1:29:13 PM: Snapshot stored, 154.4 MB 3/26/2014 1:29:29 PM: Execution completed successfully $[130402779298810000] Completed: 108 files, 1.1 GB, with 82% compression Performance: 117.4 MB/minute Duration: 10:03:59 (09:55:02 idle/loading/preparing) - 3/26/2014 1:29:30 PM: Copying $[*!20611,,14,+3]Data (E:)$[3] on win2003$[4] 3/26/2014 1:58:38 PM: Snapshot stored, 2,899 KB 3/26/2014 1:58:46 PM: Execution completed successfully $[130403141707150000] Completed: 22 files, 13.8 GB, with 64% compression Performance: 500.8 MB/minute Duration: 00:29:16 (00:01:04 idle/loading/preparing) - 3/26/2014 1:58:48 PM: Verifying $[*!20825,,14,+3]New Win2003 3/26/2014 2:03:48 PM: Execution completed successfully $[130403159288950000] Completed: 130 files, 14.9 GB Performance: 3126.8 MB/minute Duration: 00:04:59 (00:00:08 idle/loading/preparing) 3/26/2014 2:03:49 PM: Execution completed successfully Total duration: 10:38:14 (09:56:15 idle/loading/preparing) Location of backup report is $[01]D:\tmp\$[02].
  5. aesmith

    Reverting back to v8.5 from 9.0

    So can a catalog file rebuild prune these incompatible parts of the backup or do I need to recycle my backups and start from scratch keeping my fingers crossed that nothing fails until I get a new enterprise wide backup set base?
  6. aesmith

    Reverting back to v8.5 from 9.0

    That would make sense. Only very few clients seemed to have used the block level and this was one of them.
  7. Due to instability I have had to revert back to Retrospect version 8.5. Are the backups created by version 9.0 compatible with 8.5? Things for the most part seem to be working using the last backups created by version 9 but right now when trying to recreate a catalog file that was corrupted due to v9 crashing, I am getting > Backup Set format inconsistency (2 at 638214404) over and over(like 1000s of them).
  8. aesmith

    V9 scheduled backup stalling

    Well after 7 hours of seeming being stuck it continued. Something definitely wrong, but not a total lockup of this backup task.
  9. I have another issue that seems to be related to the v9 upgrade from v8.5 on Windows based machines. One scheduled task that backs up our older sbs2003 standard computer is also stalling. This backup used to take about 45 minutes but now after completing 1 of 2 parts it seems to stall on the building snapshot. Instant scan is turned off along with block level incremental backup is off too. Here is what the log says under v9 + Normal backup using win2003 at 3/14/2014 3:21 AM (Execution unit 3) To Backup Set New Win2003... 3/14/2014 3:22:05 AM: Connected to win2003 * Resolved container win2003 to 2 volumes: System (C:) on win2003 Data (E:) on win2003 - 3/14/2014 3:21:59 AM: Copying System (C:) on win2003 Here is what it used to say: + Normal backup using win2003 at 3/6/2014 4:43 AM (Execution unit 3) To Backup Set New Win2003... 3/6/2014 4:43:18 AM: Connected to win2003 * Resolved container win2003 to 2 volumes: System (C:) on win2003 Data (E:) on win2003 - 3/6/2014 4:43:12 AM: Copying System (C:) on win2003 3/6/2014 5:00:26 AM: Snapshot stored, 156.6 MB 3/6/2014 5:00:38 AM: Execution completed successfully Completed: 217 files, 1.2 GB, with 80% compression Performance: 126.5 MB/minute Duration: 00:17:25 (00:08:27 idle/loading/preparing) - 3/6/2014 5:00:38 AM: Copying Data (E:) on win2003 3/6/2014 5:26:36 AM: Snapshot stored, 3,466 KB 3/6/2014 5:26:45 AM: Execution completed successfully Completed: 25 files, 13.8 GB, with 63% compression Performance: 561.4 MB/minute Duration: 00:26:07 (00:01:02 idle/loading/preparing) - 3/6/2014 5:26:49 AM: Verifying New Win2003 3/6/2014 5:33:00 AM: Execution completed successfully Completed: 242 files, 14.9 GB Performance: 2527.8 MB/minute Duration: 00:06:11 (00:00:10 idle/loading/preparing) 3/6/2014 5:33:02 AM: Execution completed successfully Total duration: 00:49:47 (00:09:40 idle/loading/preparing) 3/6/2014 5:33:03 AM: Script "win2003" completed successfully
  10. Since upgrading to version 9 of Retrospect single server backing up about 30 clients here via proactive backup I have been seeing the occasional error 832 (see below). This I think is specific to the new block level backup but don't understand what it means exactly? + Normal backup using Desktops - dbanks at 3/14/2014 8:37 AM (Execution unit 1) To Backup Set dbanks... - 3/14/2014 8:37:51 AM: Copying OS (C:) on dbanks Backing up -22 files using block level incremental backup. 3/14/2014 8:59:14 AM: Snapshot stored, 301.8 MB 3/14/2014 8:59:41 AM: Execution completed successfully Completed: 289 files, 6.9 GB, with 98% compression Performance: 899.2 MB/minute Duration: 00:21:50 (00:14:01 idle/loading/preparing) Can't access volume , error -832 ( refnum's controller doesn't exist) 3/14/2014 8:59:49 AM: Execution incomplete Total duration: 00:21:50 (00:14:01 idle/loading/preparing)
  11. aesmith

    Block Level Backup for VMware

    Gee thought I looked through all the options and did not see that it had to be turned on, thanks I will give it a try.
  12. aesmith

    Block Level Backup for VMware

    I think in theory it should but my experience has been that I have not seen any indication of block level backup is working. I was very excited to update to version 9 of Retrospect single windows server because many users have large PST files and a few virtual xp disks. I was thinking the block level backup would make the backup of these files a lot faster/more efficient. I have not witnessed block level backup do anything yet. I have only been on v9 for 5 days though. For that matter I rarely see the instant backup kick in though.
  13. aesmith

    Windows V9 slower than V8.5?

    I have been watching it do this "offsite" backup to usb HD and it seems the real slowness is that at the end of each round of backup (each backup set often has 7 sub parts) it get stuck spinning its wheels. It goes through repeated rounds of Matching/updating catalog files but not progressing like it used to.
  14. aesmith

    Windows V9 slower than V8.5?

    Maybe this will help shed some light on it as well. Here is the 2nd backup shown above V9.0 showing speed of 759 + Executing weekly offsite mghais at 3/9/2014 2:50 PM (Execution unit 1) To Backup Set Backup Set A... - 3/9/2014 2:50:48 PM: Transferring from mghias - 3/9/2014 2:50:48 PM: Transferring from mghias 3/9/2014 2:50:48 PM: Execution completed successfully - 3/9/2014 2:50:48 PM: Transferring from mghias 3/9/2014 5:45:55 PM: Execution completed successfully Completed: 879849 files, 152.1 GB Performance: 910.3 MB/minute Duration: 02:55:07 (00:04:04 idle/loading/preparing) - 3/9/2014 5:45:55 PM: Verifying Backup Set A 3/9/2014 6:23:29 PM: Execution completed successfully Completed: 879849 files, 152.1 GB Performance: 4315.0 MB/minute Duration: 00:37:33 (00:01:28 idle/loading/preparing) 3/9/2014 6:24:18 PM: Script "weekly offsite mghais" completed successfully V8.5 showing speed of 1808 + Executing weekly offsite mghais B at 3/1/2014 5:44 PM (Execution unit 1) To Backup Set Backup Set B... - 3/1/2014 5:44:45 PM: Transferring from mghias OS (C:) (2/26/2014 3:02 PM) 3/1/2014 7:08:44 PM: Execution completed successfully Completed: 880775 files, 139.1 GB Performance: 1926.8 MB/minute Duration: 01:23:55 (00:10:03 idle/loading/preparing) - 3/1/2014 7:08:44 PM: Transferring from mghias OS (C:) (2/28/2014 10:50 PM) on Client "mghias" 3/1/2014 7:22:01 PM: Execution completed successfully Completed: 7260 files, 20.8 GB Performance: 1620.3 MB/minute Duration: 00:13:13 (00:00:10 idle/loading/preparing) - 3/1/2014 7:22:01 PM: Verifying Backup Set B 3/1/2014 8:01:47 PM: Execution completed successfully Remaining: 1 files, zero KB Completed: 888034 files, 159.8 GB Performance: 4196.5 MB/minute Duration: 00:39:45 (00:00:45 idle/loading/preparing)
  15. This is the first weekend our offsite backups have run under the new version 9 of the Windows single server Retrospect. This is done via a 2 TB usb 3 connected hard disk. Generally this task has been completed easily between Friday night and Monday AM, but I come in today and see it is only about half done. Comparing the reported performance values I can see why. Here is some examples for the same three backups V8.5 = 1283/1808/1297 V9.0 = 903/759/751 You can see a huge difference in transfer speed. Nothing else has changed in the system other that upgrading the version of retrospect. Any ideas why this would be the case? Allan
×