Results 1 to 6 of 6

Thread: Writer status is not stable. Try after restarting application Writer service.

  1. #1
    Join Date
    Mar 2014
    Posts
    4

    Default Writer status is not stable. Try after restarting application Writer service.

    I've been happily using ZCB for at least three months with little issue. I use it in two environments - one is a host server running Windows Server 2012 R2 and has scheduled backups for Hyper-V VMs, System State, and File System. The other is a Windows Server 2012 R2 VM that serves as our SQL server, with corresponding backups.

    Every now and then, I would get the "Writer status is not stable. Try after restarting application Writer service." error when trying to perform a backup. This is more frequent on the host server than it is on the SQL Server VM. Sometimes, using the "Restart Background Service" function under Tools will resolve the issue. At other times, this has no effect, and only a full system reboot will allow backups to continue. I found that a system reboot was commonly necessary every 1-2 weeks to mitigate the issue. This was an inconvenience, but not a burdensome one.

    However, after updating ZCB to 4.11, I have encountered this error with a much higher frequency. For example, I performed a full system reboot this past Friday evening, so that all weekend backups would be performed without the issue. Upon coming into the office Monday morning, I have discovered that almost every backup failed with this issue, including the backups on the SQL Server VM, which to this point, has very rarely seen this issue. In addition, using the "Restart Background Service" function has not made a difference.

    It is not feasible for me to be able to reboot the server again until the July 4th holiday begins, so I am likely stuck without backups until then, though as the weekend has shown, a reboot is no longer a guaranteed fix. I am looking for any tips, tricks, or best practices to make this error less frequent. If this should be submitted as a support ticket, I would be happy to do so. Please let me know, and thank you for any help.

  2. #2
    Join Date
    Jan 2012
    Location
    Oklahoma
    Posts
    128

    Default

    Hi,

    That error means that one or more of the VSS writers required for backup are failing for some reason.

    Writers almost always fail for a reason. Normally this has little to do with the backup application itself, although it can happen if the application is feeding the writers data it doesn't understand. That's pretty rare though.

    If things are broken after an upgrade, I recommend you uninstall ZCB. During uninstallation you will be asked if you want to preserve configuration. Say yes. Then reinstall.

    If the issues continue after that, please enable DEBUG logging, reproduce the error, and send logs as shown here: [url]http://help.zmanda.com/x/uAI6[/url]

    Then open a support ticket and let us know about the logs you just uploaded. We'll see what's causing the writers to fail.

  3. #3
    Join Date
    Mar 2014
    Posts
    4

    Default

    Eric,

    Thanks for the response. Uninstall/Reinstall had no effect, so I created a support ticket and uploaded my logs.

  4. #4
    Join Date
    Jan 2012
    Location
    Oklahoma
    Posts
    128

    Default

    I wanted to post an update to this thread.

    The root cause of this particular issue was overlapping backup schedules in multiple backup sets, mostly of the same SQL Server on one of the guest VMs that was backed up both from the Hyper-V host and from within the guest VM itself.

    This is actually one of our most common support cases. The issue stems from the way that Microsoft's various databases themselves are designed and not from any particular failing of ZCB. This particular issue was a bit confusing due to the interaction between the Hyper-V image-level backup of the guest VM and the SQL backup from within the guest VM.

    This was a rather fun one to work on; it gave me a chance to write up a detailed summary of this issue and why it occurs.

    For posterity's sake, here's a summary of the behavior, and how to avoid it.

    The various Microsoft databases (Exchange, MSSQL, Sharepoint (which has a MSSQL component), etc) do not behave well when backed up by multiple sources if incremental or differential backups are involved. These databases don't keep track of which source did the backup. Only that a backup occurred.

    The reason being that the transaction logs are committed/purged//truncated (pick a verb) during full or incremental backups. An inc/diff backup can't function if it can't pick up where the previous backup left off. Fulls are unaffected because they just grab everything regardless of backup history.

    Imagine this timeline:

    Backup A takes a full backup at 6:00. All is well.
    Backup A takes an incremental backup at 7:00. All is well.
    Backup B takes a full backup at 7:30. All is well.
    Backup A takes an incremental backup at 8:00. The incremental backup fails, because the backup from Backup B modified the transaction log history at 7:30. The VSS Writer that controls the backup goes into a Failed state. No further incremental or differential backups for Backup A will work until Backup A takes a new full backup.

    Backup B takes an incremental backup at 8:30. All is well, since transaction logs are still based on Backup B's backup at 7:30.
    Backup A takes a full backup at 9:00. All is well (Unless it's Exchange, see below).
    Backup B takes an incremental backup at 9:30. The incremental backup fails, because the backup from Backup A modified the transaction log history at 9:00. The VSS Writer that controls the backup goes into a Failed state. No further incremental or differential backups for Backup B will work until Backup B takes a new full backup.

    It can get complicated when you toss image-level backups into the mix. Many of those will interface with VSS on the system that they're imaging in order to get consistent backups of the databases within the system. ZCB's own Hyper-V backup does this for guest VM images. Veeam, ShadowProtect, and even Windows Server Backup do it as well. It's common.

    For MSSQL, the VSS writer will recover automatically (usually) when the next full backup is attempted, but for Exchange, you'll have to restart the Microsoft Exchange Information Store service manually to recover the writer. All VSS-based Exchange backups, including fulls, will fail until the MEIS service is restarted.

    If you have multiple backup sources and databases are involved, you should stick to full backups only, pick just one source, or time things so that the backups aren't stepping on each other's toes.

  5. #5

    Default

    Is amanda cloud backup feature available only for windows??
    If its available in linux where can i find the documentation on that.



    ______________
    You can check out our latest [url=http://www.pass4sure.co.uk/ICND-1-training.html]200-120 vce[/url] and testking exams written by our [url=http://www.pass4sure.co.uk]ccna voice 640-461 official cert guide[/url] to help you pass [url=http://www.pass4sure.co.uk/642-902.html]ccnp security certification[/url].You can also purchase [url=http://www.mines.edu/]mines.edu[/url]. Our [url=http://www.northwood.edu/]northwood[/url] is simply excellent in quality.
    Last edited by alinamike; January 20th, 2015 at 12:09 AM.

  6. #6

    Default

    You can use Amanda Enterprise to backup linux servers to cloud.
    [URL=http://amanda.zmanda.com/]Amanda backup and recovery [/URL]
    [URL=http://www.zmanda.com/backup-mysql.html]MySQL backup and recovery[/URL]

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •