none
Windows Server Backup May fail the Exchange Consistency Check RRS feed

  • Discussione generale

  • Salve, 

    ho un server SBS2011 STD con Exchange 2010 Standard SP3 e circular logging abilitato.

    Quando eseguo un backup con Windows Server Backup del disco in cui è contenuto Exchange, il backup fallisce con un messaggio di non coerenza di Exchange.

    Ecco gli eventi:

    Nome registro: Application

    Origine:       Microsoft-Windows-Backup

    Data:          11/11/2013 09:01:03

    ID evento:     565

    Categoria attività:Nessuna

    Livello:       Errore

    Parole chiave:

    Utente:        SYSTEM

    Computer:      SBS2011.borellomangimi.net

    Descrizione:

    Verifica di coerenza per il componente '42feaee9-0b5c-475b-903f-579a6b39990d'\'Microsoft Exchange Server\Microsoft Information Store\SBS2011' non riuscita. L'applicazione 'Exchange' non sarà disponibile nel backup creato alle ore '‎2013‎-‎11‎-‎11T09:00:12.854514800Z'. Per informazioni sui problemi relativi alla verifica di coerenza, esaminare i dettagli dell'evento.

    Nome registro: Application

    Origine:       MSExchangeIS

    Data:          11/11/2013 09:14:03

    ID evento:     9782

    Categoria attività:Exchange VSS Writer

    Livello:       Errore

    Parole chiave: Classico

    Utente:        N/D

    Computer:      SBS2011.borellomangimi.net

    Descrizione:

    Exchange VSS Writer (istanza a8c14b37-5891-45e6-b659-9a1ecd11dd55:11) ha completato il backup del database 'Public Folder Database 1535012976' con errori. Il backup non è stato completato correttamente e nessun file di registro è stato troncato per questo database.

    Nome registro: Application

    Origine:       ESE

    Data:          11/11/2013 12:40:06

    ID evento:     2007

    Categoria attività:ShadowCopy

    Livello:       Errore

    Parole chiave: Classico

    Utente:        N/D

    Computer:      SBS2011.borellomangimi.net

    Descrizione:

    Information Store (7960) Istanza della copia shadow 12 interrotta.

    Ho testato i database ed i log secondo la procedura descritta nella KB2616952, ma non sono stati rilevati errori.

    Qualche idea in merito?

    Grazie

    • Tipo modificato Anca Popa mercoledì 20 novembre 2013 15:52 discussione in corso
    giovedì 14 novembre 2013 10:11

Tutte le risposte

  • Questo dovrebbe essere il tuo caso:

    http://support.microsoft.com/kb/2616952

    Roberto


    Roberto Ferazzi

    IT Consultant | Microsoft MCTS MCITP MCSA MCSE MCT | http://www.ferazzi.it

    If you found my post helpful, please give it a Helpful vote

    If it answered your question, remember to mark it as an Answer

    giovedì 14 novembre 2013 11:51
    Moderatore
  • Buongiorno Roberto,

    purtroppo come ho scritto avevo già cercato e provato questa KB, ma non vengono segnalati db o logs danneggiati.

    Che altri test posso eseguire per individuare e risolvere il problema?

    Claudio

    giovedì 14 novembre 2013 11:56
  • Dalle ricerche ho trovato che il componente '42feaee9-0b5c-475b-903f-579a6b39990d' segnalato nell'evento è il Public Database.

    Idee su come procedere?

    giovedì 14 novembre 2013 15:12
  • Il contenuto della KB2616952 si applica anche al DB delle Public Folders.

    Prova ad applicare quanto descritto, facendo riferimento al Public Folder Database.

    Roberto


    Roberto Ferazzi

    IT Consultant | Microsoft MCTS MCITP MCSA MCSE MCT | http://www.ferazzi.it

    If you found my post helpful, please give it a Helpful vote

    If it answered your question, remember to mark it as an Answer

    giovedì 14 novembre 2013 20:42
    Moderatore
  • Ho già eseguito sia eseutil /k (come descritto nella KB2616952) sia eseutil /g su entrambi i database non ottenendo alcun errore.


    venerdì 15 novembre 2013 13:57
  • Qualcuno sa quali altri controlli posso provare ad eseguire?

    Il componente in questione è il Public Folder Database che però non viene segnalato corrotto e non vi è alcun errore neanche col checksum.

    Grazie per l'aiuto.

    lunedì 18 novembre 2013 08:20
  • Ciao,

    allora prima di tutto non si abilita il circular logging di solito su un db Exchange in quanto se il db viene corrotto o compromesso, esso non può essere completamente restorato se sono stati aggiunti altri dati al db prima del tempo di un ultimo full backup.

    Il circular logging fa l'owerwrite di ogni TL transaction logs di Exchange server e viene abilitato quando si usa Exchange nella funzionalità di native data protection.

    Di default è disabilitato su exch 2010 e 2013....

    Pertanto esistono due metodi per truncare i transaction log di Exchange:

    - o abilitando il circular logging (sconsigliato per i motivi suddetti)

    - o facendo un backup di tipo VSS (shadow copy) o ad esmpio tramite Windows backup o con sw di backup terzi che lo supportano

    Quindi in primis ti consiglio di disabilitare il circular logging sul db Exchange e impostare il backup del db di exchange nel metodo seguente :

    http://msexchangeteam.in/how-to-backup-exchange-server-2013-database-part-1/

    ti consiglio anche l'ascolto di questo post fatto da Fabrizio Giammarini http://technet.microsoft.com/it-it/video/come-spostare-i-transaction-log-di-exchange-senza-fare-danni.aspx

    fammi sapere 

    Mattia Lodi

    giovedì 21 novembre 2013 10:27
  • Buongiorno Mattia,

    grazie per lo spunto. 

    Ora approfondisco il materiale che mi hai postato. Ti darò un feedback nei prossimi giorni.

    venerdì 22 novembre 2013 08:44