Jump to content

A+ Computers

Members
  • Content Count

    1,587
  • Joined

  • Last visited

  • Days Won

    207

Posts posted by A+ Computers


  1. For a single user, yes, its not as great a deal as some of the others out there.

     

    Its strength is that you sell blocks of storage, not license individual computers. So if you have an office with 10 users, you only need to buy one or two blocks, instead of ten licenses. 

     

    For example, I have a client with 500 seats. They bought 20 blocks of storage. We are charging the client $176/month for that. With Mozy, that same storage capacity would be $192.48/  month if you add in backing up to a server.

     

    Also, the AVG backup is monthly billing. Many of the other online backup services, while they show the monthly cost, are billed in 1-2 year increments. So if after a few months, they decide that the service isn't for them, with AVG you can cancel the service. With others, you have already paid for the year up front, so you are either locked in or throwing your money away.


  2. may have figured it out via a remote session to the clients server. 

     

    They set these mailboxes up roughly 18 months ago. When they set them up, their exchange admin did not enable circular logging.... So their 9GB mailbox that does show up is actually 32GB on disk when you include all of the log files. Their 245GB mailbox that isn't showing up is actually 800,000+ files and 1.07TB on disk..

     

    So I think that OLB may just be timing out when it is trying to total up the files to figure out how much data there is to back up. I directed them to exchange manager and explained to their exchange admin how to enable circular logging and to let that clean up the log files over the weekend before trying again. It took about 15 min for the 9GB mailbox to purge all of the log files and commit the changes, so were're guessing the client is looking at a couple of hours at least for the 245GB mailbox to commit the changes and purge the log files.

     

    Really glad the client trusts us enough to let me take a look at their server config with them, otherwise we probably would not have discovered the nearly 2TB worth of wasted space across two servers as the DB's are mirrored on a backup server as well.


  3. I have an large client running multiple databases on one of their exchange server. When they try to configure the exchange OLB, the are only shown the first database for backup. They really need to backup the second, 200GB database.

     

    I've never run into a similar situation with a client before so was wondering if there was any way of forcing OLB to see both of the DB's or if it is just limited to a single exchange DB.

     


  4. I'm loathe to do that as I will need to reconfigure the backups again after that (they are not policy based). 

     

    According to the client summary log, the only update that has happened since the machine that finished its backup at noon is an av update that happened about 45 minutes ago, long after I started this topic.

     

    Oh, and you may want to add yourself to the avg staff group if you are staff, or post with a staff account.


  5. Just looking at a client account (TRA002 in my portal) and seeing that 3 of their 6 machines are showing that the OLB component is not installed. 

     

    2 of the three show as being online and show the connect button. All three of them have run backups within the last 7 days. One of them even shows it ran a backup an hour and a half ago!

     

    As i can confirm that none of these have had the OLB component removed, I can only assume that this is related to the issues we are seeing with Remote IT at the moment.

     

    If it is not, I'm frankly scared of the fallout from this if it turns out we have other clients showing that OLB is no longer installed and it's not related to the remoteIT issues that are ongoing.

     

    Please AVG, tell me it'll be all better next week and I won't have to reconfigure OLB on on a bunch of workstations.


  6. That does shed light on the situation.

     

    In that case then, maybe the "delete data" button should be labeled as "delete data & remove service". 

     

    Also, automatic re-authentication once every 24h is pretty terrible. If i have to make a policy change to a 100 seat company, that means I have to go to each workstation and re-authenticate manually if I need the change to be live right now. I would much rather see the agent machine poll once ever 5-10 minutes and all other wokstations poll that agent machine for changes.


  7. Can confirm that it is once again working after re-authenticating manually. I did however have to configure the backup from scratch.

     

    If I had left the service uninstalled in the portal after deleting the data and just re-authenticated manually, would it have shown up as having the service installed in the portal? If so, I'm guessing that it would have retained the backup settings that were lost when I re-deployed the service through the portal.

    I'm still perplexed about two things though.

     

    1. Why would the portal show the service as not being installed after simply deleting the data?

    2. Why didn't the endpoint re-authenticate itself after 3 hours? 


  8. While working with a client to move some files around on their PC to reduce the size of the backup set, I logged into the portal and clicked "delete data" from the device screen. It asked me to enter the backup password, and then I would expect it to simply remove the data on the OLB server. 

     

    What I have observed in actual practice is that it appears to uninstall the service from the PC (according to the portal), showing the service no longer installed on the device you just deleted the data for. 

     

    When I re-deployed the OLB service from the portal and restarted the workstation, when logging back into the OLB endpoint software, I am now told that the backup account has been disabled. I have verified that the backup service is still offered in customer profile and services. I even hit the save button just to be sure.

     

    Is this just a timing thing? Do I need to give it a few hours? Usually If I need to remove data from a backup I do it through the restore menu on the end point, but in this case, as I was removing everything and starting the backup again from scratch I removed the data through the portal. This method requires me to wait an hour or two until the changes to the backup size are reflected in the portal and in the end point software.

     

    If this is expected behavior, then the "delete data" button needs to be reworded to "delete data and remove service".


  9. What backups to you have set? Is it only files and folders? If so your findings do indeed not make any sense. If its SQL or exchange data, its probably to do with the retention period you have set. Check to make sure that the retention period lines up with your "full" backup schedule. If not, the "full" backup is being purged as per your retention period.

     

    Example:

     

    Retention period: 1 days

    Full backup: every 2 days

    Incremental backup: every 1 days

     

    You run the initial backup, which is a full backup on day 1

    Day 2,it runs an incremental backup (just the log files basically) and purges the full backup causing your spaced used to drop

    day 3, the full backup runs again


  10. I can now confirm that the new OLb will require you to install the 2012 management objects package, which in turn requires you to install the 2012 clr type package and that they will both install on previous sql versions without error. Both seem to be backwards compatible with at least sql 2008 r2, even though I could not find any info about the compatibility of the clr types package.

    After installing both packages, the OLB component for SQL runs properly and the gui seems to be unchanged from what you are used to seeing.


  11. Ok, so it looks like the management objects for 2012 are backwards compatible with previous versions. The 2012 management objects do however require that the CLR type objects package be installed.

    Only questions remaining are:

    1. Can I use the 2008r2 CLR type objects with this, or do I need to install the 2012 CLR type objects?

    2. Tf I have a SQL 2014 install that I need to backup ( I don't at this time, but will in the future) will the new SQL OLB ask for the old 2012 management objects, or will it work properly with the 2014 management objects package, which is backwards compatible down to SQL 2005?


  12. Its been a few days now and I still haven't been able to backup the clients SQL database. I've installed the management objects for SQL2008r2, which is what the client is running and it still tells me I need the SQL 2012 management objects installed. This is a medical office and they rely on their SQL database for patient info and it needs to be backed up daily. I'm not willing to risk putting them out of business for a couple of hours because the new "improved" version of the OLB client can't do what it did before without needing extra software installed to do its job.


  13. I understand needing to install some management objects for SQL now, but the message you get when first trying to setup the SQL backup without the management objects installed tells me to install the management objects for SQL 2012 on a 2008R2 server running SQL 2008R2....

    Is this just an oversight, or am I expected to install management objects for a newer version of SQL on the servers running older versions of SQL?


  14. I did, I'm not sure how I did as I didn't do anything. After alerting AVG to the issue, I was asked for some log files, after gathering the log files (and before sending in the log files) I tried the backup again. It worked properly.....

     

    Try restarting the online backup service if the computer you are having trouble with has not been restarted in a while.


  15. I've started getting this error on a client account. They have two machines sharing a single block and both receive this message when trying to run their backup;

    They had gone over their block a week ago, so instead of purchasing a new block they archived some of the older files that were included in the backup and removed them. I then cleaned out the backup data for the machine they archived the files from and left it to re-sync on the next backup.

    Now whenever the backup runs on either machine, it fails with this message in the endpoint details.In the log file I see this:

    exitCode=0, backupType=0, isScheduled=0, isCancelled=1, serverPolicyUsed=0, duration=0, nextRunTime=2014/7/1 0:0:0 uploadedCount=0, uploadedSize=0, errorCount=0, errorSize=0, unchangedCount=0, unchangedSize=0, totalCount=0, totalSize=0

    Both in the end point software and the dashboard, data use is shown at around 140MB after cleaning out the old data


  16. I have a client server with a rather hefty SQL DB (12GB). I noticed the other day that compared to to other clients, this one always took a day or two to run its full SQL backup. 

     

    When I took a look at the SQL backup in progress, I saw that it was only uploading at around 170Kbps

     

     

    Well there's your problem!

     

     

    This client has a 5Mbps upload on a cable connection, tested to multiple servers around the US on speedtest.net, so rule out a bandwidth issue.

    The raid array the data is coming off of is not being taxed at all. its barely at 50% IOPS of its max. Rule out hard drive issue

    Ok, what about CPU and memory? CPU is sitting at about 1% usage across all cores, but RAM,  RAM allocation was at nearly 100% with only about 100MB of "free" RAM.

     

    This server has a measly 24GB or ram, but it should be more than enough as it is a SBS 2011 box for a small office office of 10 users. Its running AD, exchange, shared storage and hosts their SQL DB.

     

    Normally we set the mix/max cache size for exchange at 1GB/4GB as the exchange store will gobble up all available RAM if left to its own devices, but apparently this step was missed when configuring the server as the exchange store was presently feasting on about 13GB of RAM, all for a 2.4GB exchange database.

     

    After taming the exchange beast and restarting the service, I re-ran the offending SQL backup. It is presently chugging along at around 900Kbps,-1Mbps 

     

    quite the improvement

     

    If you would also like to tame the exchange beast, the following is a step by step guide to setting the min/max cache settings for both exchange 2007 and 2010. it may improve your server's upload speeds with OLB as well. Remember to backup before messing with things, i take no responsibility for your blundering when you down an exchange server currently in production in the middle of the day.

     

    http://www.bursky.net/index.php/2012/05/limit-exchange-2010-memory-use/

     

     


  17. Kodeman, for the time being, on the affected computer, open up task scheduler and remove or disable the avg backup tasks. They should be labeled as such and easy to find. That will at least stop the client from attempting to backup for now.

     

    Sean, if the client is unaware of deactivation, does that mean a self managed client could potentially install the client, remove it from the portal, then install the client on another computer, leaving them with 2 functional end points but only 1 license in use?

×
×
  • Create New...