Showing results for 
Search instead for 
Did you mean: 

Sorely needed improvements

Level 3

I've started using SPN Remote Backup in the last month after failed stints with Iron Mountain Online Backup [pricey, but easily the smartest backup agents] and MozyPro [incredibly inexpensive, but very poor backup agents] and want very badly to love the product.  I already have a few issues and I would like to know timeframes (at least very general ones) for their inclusion into the product.


1) Reporting is HORRID.  It tells me next to nothing about what I care about.  The last thing I need is a pie graph (with no actual numbers) showing me my disk usage.  I have no idea whether or not it's working since the reporting is so bad.  It frequently tells me that I have 100's of errors and shows me only the last one.  The reports don't tell me which files have failed, which is really quite necessary for me to judge whether or not my backup can be considered a success.


2) Open files cannot be backed up.  Is this likely to change?  If so, when?  I don't know how Iron Mountain's Online Backup solution managed it, but it was quite good.  Mozy tried to use Windows Shadow Copy Service, but failed miserably especially on large files.


3) Communication with customers needs to be improved.  I really don't get the feeling that Symantec cares about this product.  In my opinion, this market could be dominated by Symantec if they really felt like it.  There are so many players out there that are putting out mediocre products and the ones that do it right are charging an arm and a leg.  I'd like somewhat frequent updates on what we can expect from SPN Remote Backup in the near (as well as distant) future.  Companies that tout remote backup as their flagship product really make the customer feel important through frequent communication with end-users.  Symantec has one man (albeit a good one) responding to message board posts and not much else going on.  Should I really get behind such an anemic effort?


I hate to pick apart the product because I REALLY do want to love it.  I just want to see that things are moving in the right direction and know what to expect.


Level 4



First off, thanks for trying the service and being very frank with your input :)


I'll try to answer each question in succession:


1) Reporting:  I think you are actually touching on two areas here, where one is Reporting (historical views of backup/recovery information) and "status" (what actually is going on, or just went on, with your backups). It sounds like you are more concerned with "status", so let me talk about that one for a minute. 

We definitely have improvements under way as we speak in this area, focusing specifically on the type and number of alerts we raise, as well as how we display status and historical "logs" of successes and failures. This is a high priority effort for us and will be rolled out as soon as possible.  It will specifically address things like which files failed and for what reasons.


2) We do support open files, in fact we try several times throughout the day to protect open files. For example, my own PST files (locked and in use by Outlook) are backed up 3 times per day, sending only the changed bytes. Are you seeing files that aren't specifically backed up? The best way to tell right now is to see if the files are available under the Restore step. If they are not there, please engage with our support to ensure that we find out why specific  files are failing. The solution is meant to be truly "set it and forget it", and we should not be missing any files. 


3) Communications with customers: I like to think we are doing well in this area, so I'd like to find out exactly where you would like to see improvements. Today we communicate via the following methods: 


  • The SPN forums: (where we are currently). We have several employees monitoring, including PM (myself) and Customer Care (usually Ted jumps in here).  We accept support requests, post news about new features and releases, and ask for feedback. Posts are always answered, sometimes within minutes.
  • The SPN Blog: - Similar to the forums, we post new release information, discussion topics, and industry observations. Anyone is welcome to comment and communicate with us to ask for new topics, etc.  I'll also be posting sneak peeks of new features/changes as they near release. 
  • Email mailings: Although we try not do too many, we do send out important service notices and updates.
  • Customer Care contact: You can always contact customer care via email, phone, or via the Support page in the portal.

We definitely value all feedback, positive or negative. I hope this reply addresses some of your concerns; if not let's continue the discussion.



Richard Goodwin

SPN Product Management

Message Edited by Richard Goodwin on 10-30-2008 05:40 PM

Level 3



Thanks for responding.  You're right, I did touch on a two different issues with the first point, so let me clarify.  The issues affect each other since I try to verify one with the other.  If you read on, you'll understand what I'm trying to say.


First off, the reporting (not status update) is horrible.  I'm generating a backup history report for one of my machines and I'll walk through it in this post here.


*Twiddling thumbs as report runs* (note: completely acceptable wait time in my opinion)


 I ran it for a machine that is currently do its initial seed backup with 60GB of data.  It's completed about 6GB.  I chose to see the details rather than an overall summary.


First off, I don't work along the same longitudinal line as Greenwich, and I don't think in GMT.  Reports need to be changed to accomodate local time zones.  I understand why it happened initially, but it should be pretty simple to change.  I think I read elsewhere that this was going to be changed in the future, but the tech support employee I spoke with had not heard the same thing, thus I'm mentioning it again here.


Moving on, the Report Criteria on the right side of the report truncates in both the "Customer" field and the "Created By" field.  It's a small gripe since I can usually figure out what the endings are, but it'd be nice to have it fixed.


I'm not presented with 3 graphs.  The first one, Storage Statistics, is a pie graph showing me Available Storage, Existing Consumption, and New Consumption.  I'm offered no numbers at all, so these are just somewhat useless approximations for me.  The next graph is a bar graph titled "Top 5 Consumption by Computer."  As I only ran the report with one server, there is only one bar.  Had I run the report with multiple servers, I'd have no idea what bar corresponded to what server since all of the names are truncated after about 16 characters into the name.  Since the Symantec default is to name each computer with the following format "%DOMAIN%-%SERVERNAME%", I see "MYDOMAIN.LOCA..." next to each bar in the graph leaving me with no idea what server's usage is being graphed.  The third graph, "Backups by Date" is passable, but not incredibly useful.


Now we're moving to the specific issues with reporting that are inexcusable.  I ran a report to give me details about the last 7 days [Oct 27 - Nov 3] on SERVER-ALPHA.   Let me tell you what it says in the "Backup Summary By Systems" section of the repot.  No data was returned.  Please broaden the report criteria and try again.  Fair enough, that must mean that no data was changed on SERVER-ALPHA and thus not backed up, let me just try to verify that.  At this point, I head over to the specific computer profile page for SERVER-ALPHA and check the event history for the last 7 days.  I click details for 10/29/3008 at 9:51:39 AM.  Lo and behold, 241 files were copied for a total of 3.5 MB along with 17 errors.  [Side note: What does an error mean?  Did it eventually succeed, but initially threw an error?  I'd like to investigate further, but there are really no means to do so.]  The real issue here is that my report said there was simply no activity in the last 7 days and the event history in the computer profile begs to differ.  And what were the other 16 errors?  I'm not allowed to see them, so it's awfully hard to take any action to avoid them in the future.


I'm glad to see that open files are handled, I must have received some misinformation somewhere about that.  I'd love to be able to see how this is handled by checking a log of some sort, but that seems to be an impossibility.  Do you use VSS?


As far as communication goes, I'm looking for a company that is very open about what is or isn't being developed.  I find it extremely frustrating to receive a response akin to "We'll have that in the future." or "It's being worked on."  I understand that nothing is set in stone when it comes to development deadlines and customers try to hold you to any sort of timeline you make available and this is why things are kept someone secret.  However, simple updates such as "The development team thinks that feature X couldn't possibly be completed before Quarter Y of year ZZZZ" would be ever so helpful.  In my case, I'm evaluating this software for our company along with others.  If there is a feature that is near and dear to me that hasn't been implemented, it means a lot to me to have a piece of information about when it may be implemented (beyond "sometime in the future").  I'm waiting on pins and needles for any news on the feature and a bit of informal insight goes a long way and makes the customer feel like less of a hostage.


In the end, I'm really sick of looking around for an acceptable, mature, affordable remote backup service.  I'm confident that Symantec has the resources to do it correctly and I want it to be my final choice, but it's definitely not there yet.





Level 3

I'd like to touch on one more issue that I think is of utmost importance.


The speed of the backup is quite poor.  I have a 70 GB seed backup that I started on Oct. 30th.  It is now Nov. 4th and it's 11% finished.  At this rate, it will take me a month and a half to finish the initial backup.  There needs to be an option to send a CD in for the initial backup or the speeds need to improve.  My back of the napkin calculation tells me we're transferring around 150 kbps or 18 KB/s (slightly faster than ISDN speed).  That would have been awesome in 1995.  Is this issue being dealt with?  What needs to be done from Symantec's side to improve this?  How long can something like that take?  I understand that speed is less of an issue after the initial backup, but getting to that point is a long way off.

Level 4

Wow, now those are some details :)


Let me start off with a blanket statement, that of course isn't ideal but I'll do my best to explain why:


Sometimes  we'll more than happily provide expected dates for a change, and sometimes we won't. The reasons are pretty straightforward (and in no particular order):


  • We don't want to set false expectations. If a feature or fix is scheduled for a certain date, and slips, we don't want to have people "setting their clocks" waiting and then be disappointed. I know it's still disappointing in the mean time to not have the feature or fix, but to have hopes and have them quashed is even more negative in my opinion.
  • We are constantly updating and revising the services based on user feedback. This means things can change in priority (and then see my first point).
  • Certainly there is a competitive aspect to be concerned about. Providing advanced information (especially if the information is not complete or subject to change in nature before release) puts a company in an odd position when participating in an established market, where that information can be used for competitive comparisons and projections.

With all of this said, I'm pushing to get us to release more information about features as they come closer. If we say a feature is going to be fixed, then that means it is a committed engineering deliverable that will be going into the service. If we say it's a very high priority, typically this means a committed feature within a 2-3 month period (with the understanding that quality testing can sometimes extend this). That said, I can't overemphasize the "typically" part: we value stably and high quality releases over dates or speed of change. 


I know it's not the ideal answer many are looking for, but I'll continue to try to evolve our messaging and sharing model with our customers to best answer questions and concerns.


Now, on to some of your additional points.


  • GMT date usage: this is being fixed in a future release. It's not on the high priority list, but it is a known pain point and will become more specific to the user interacting with the system.
  • Level of detail on reporting (and errors): I think I touched on this in my last post, but yes we have some growing to do in the amount of detail available for reporting and status purposes. Exposing the higher level of detail (including what an "error" is, more in a moment) is a high priority, committed item for us.
  • In the initial releases of Online Backup, we erred too far on the side of caution in raising events as "errors". Your guess is right; typically an error really means nothing more than "this didn't work the first time, but we tried again later and it worked fine". As part of the detailed status, this information will be made more clear and logged in your event history in finer detail.  Our model is truly "set it and forget it", we just didn't do a great job of letting you forget it ;)
  • We do indeed use VSS on some platforms, and a Symantec equivalent technology on others. 
  • Performance of seed backup: A common answer on this one is "it varies", where the variables of course are at least the following:
    • transfer rate upstream (by the way, what is your upstream speed benchmarked at? For example using )
    • latency/connection quality issues in the stream between the client and our data centers
    • number and size of files being transferred (typically large files are more efficient to transfer over the internet)
    • activity rate on the source hard drive (less of an issue typically, but any overhead should be accounted for in overall calculations)
    • load on Symantec's data centers (again, this has never been an issue, we have capacity to spare, but being honest about the variables)
  • We do have customers that have uploaded over 20GB in a day, but that's typically over a very fast connection. We are going to release some minor but high priority changes soon that will improve large file transfers even more, and then some longer term enhancements around significant numbers of smaller files.  If you can provide some more metrics about your connectivity and data set, we can see if there is anything we can do to optimize in the meantime. At some point it becomes more efficient to engage with support over the phone on an issue like this, because they have direct visibility into the datacenter operations; that said I'm willing to get you as far as possible down the line!
  • As for a physical media seed backup, we have options we are investigating, and believe me I'll be making plenty of noise as soon as I can say something around progress in that area. 

We are working on marathon posting here, but I hope it's clear that we value the feedback, and in many cases are already addressing some of the problems and requests. Thanks for continuing to participate in the discussion! If there are any of these topics you'd like to see expanded on in the blog for example, please let me know.

Richard Goodwin

SPN Product Management



Level 3

Thanks Richard, I appreciate the time that went into that post.


I'm not usually this pushy, but I've just reached my limit with remote backup products over the past few months.  My frustration is a culmination of interactions with several online backup companies.  I would like to make clear that it has never been an issue with the people behind the product, it's always purely business related.  I do appreciate the calm explanations I receive from people like yourself.


I headed over to Speakeasy to test my upstream bandwidth on our T-1.  As I expected, it was close to the theoretical limit coming in at 1415 kbps.  This is during our peak business hours as well.  The disk activity for the particular server with the large initial backup isn't heavily taxed by any means.  They are small files, and I understand the overhead with that, but the actual effect I'm seeing seems quite absurd.  I checked the latency between my server and the particular Symantec server [] that I'm currently uploading to and it was a reasonable 40-50ms.  A few traceroutes didn't reveal anything particularly useful either.


I have dealt with tech support a few times on a number of issues.  Occasionally they're helpful, although more often they're not, but it's through no fault of their own.  The questions/compaints that I have simply don't have fixes for the time being.  If you really think that tech support will be helpful in the case of speeding up the uploads, I will give it a shot, but I don't really hold out much hope.


Is there a beta test program that I can sign up for to test SPN Remote Backup?


Thanks again.




Update: I spoke with tech support and they basically surmised that it was my smaller file sizes that created the overhead that is grinding the process to a near halt.  Average file size for the first 11GB is 100KB.  They said they'd look into any possible hacks to force the server to handle more small files at a time to increase performance, but they weren't very hopeful.

Message Edited by simc-pk on 11-04-2008 01:14 PM