none
Recovery Storage Group RRS feed

  • Domanda

  • Ciao a tutti,
    ho difficoltà ad eseguire il merge di una casella presente nel recovery storage group.
    Ho anche provato ad esportarla con Exmerge ma su 2GB ne esporta 1,2GB e gnera un sacco di errori nel log.
    Ho provato anche con l'eseutil /p sul db di recovery per vedere se cambiava qualcosa ma nulla.
    A questo punto volevo provare, a montare il DB restorato in un mailbox store. Mi era già successo in passato di farlo, ma non ricordo la procedura... In questo modo potrei provare a collegare la casella ad un altro utente e visualizzarne il contenuto.
    Exchange 2003 sp2 su widnows 2003 sp2
    Grazie!

    mercoledì 5 dicembre 2012 12:28

Risposte

  • Benvenuti a entrambi :-)

    Mi permetto di aggiungere un paio di considerazioni dato che spesso sul forum arrivano problemi di questo tipo.

    Le procedure di backup e restore di Exchange sono chiaramente documentate sul Technet.
    Se qualcuno le leggesse io sarei senza lavoro e ne sarei anche contento.

    Exchange 2003 Disaster Recovery Operation Guide (http://technet.microsoft.com/en-us/library/bb125070(v=EXCHG.65).aspx)

    Exchange 2007 Disaster Recovery (http://technet.microsoft.com/en-us/library/aa998848(EXCHG.80).aspx)

    Gli scontenti sarebbero più contenti se:

    1) Avessero pianificato la possibilità di un disastro (e avessero evitato situazioni sfigatissime che non stanno a descrivere :-)

    2) Avessero fatto un backup decente di AD ed Exchange invece di reinstallare tutto in un ambiente "simile" (e non sia mai che abbiano anche testato un restore prima del disastro)

    3) Invece di usare eseutil come fosse un'accetta leggessero la documentazione per capire quando serve e quando no. Voglio ribadire per la 500° volta che ESEUTIL /P NON SI DOVREBBE USARE MAI

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    • Contrassegnato come risposta OttobreRosso martedì 11 dicembre 2012 16:15
    mercoledì 5 dicembre 2012 14:03

Tutte le risposte

  • Benvenuto nel club degli scontenti per le farraginose procedure di
    ripristino di Exchange!
     
    mercoledì 5 dicembre 2012 13:16
  • Benvenuti a entrambi :-)

    Mi permetto di aggiungere un paio di considerazioni dato che spesso sul forum arrivano problemi di questo tipo.

    Le procedure di backup e restore di Exchange sono chiaramente documentate sul Technet.
    Se qualcuno le leggesse io sarei senza lavoro e ne sarei anche contento.

    Exchange 2003 Disaster Recovery Operation Guide (http://technet.microsoft.com/en-us/library/bb125070(v=EXCHG.65).aspx)

    Exchange 2007 Disaster Recovery (http://technet.microsoft.com/en-us/library/aa998848(EXCHG.80).aspx)

    Gli scontenti sarebbero più contenti se:

    1) Avessero pianificato la possibilità di un disastro (e avessero evitato situazioni sfigatissime che non stanno a descrivere :-)

    2) Avessero fatto un backup decente di AD ed Exchange invece di reinstallare tutto in un ambiente "simile" (e non sia mai che abbiano anche testato un restore prima del disastro)

    3) Invece di usare eseutil come fosse un'accetta leggessero la documentazione per capire quando serve e quando no. Voglio ribadire per la 500° volta che ESEUTIL /P NON SI DOVREBBE USARE MAI

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    • Contrassegnato come risposta OttobreRosso martedì 11 dicembre 2012 16:15
    mercoledì 5 dicembre 2012 14:03
  • Se il DB si monta ESEUTIL è inutile.

    Exmerge genera un sacco di errori.

    Quali errori ? e il log di exmerge cosa dice ?

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    mercoledì 5 dicembre 2012 14:08
  • Il 05/12/2012, Gabriele Tansini [MSFT] ha detto :

    Benvenuti a entrambi :-)

    Mi permetto di aggiungere un paio di considerazioni dato che spesso sul forum arrivano problemi di questo tipo.


    Le procedure di backup e restore di Exchange sono chiaramente documentate sul Technet. Se qualcuno le leggesse io sarei senza lavoro e ne sarei anche contento.

    Exchange 2003 Disaster Recovery Operation Guide (http://technet.microsoft.com/en-us/library/bb125070(v=EXCHG.65).aspx)

    Exchange 2007 Disaster Recovery (http://technet.microsoft.com/en-us/library/aa998848(EXCHG.80).aspx)

    Gli scontenti sarebbero più contenti se:

    1) Avessero pianificato la possibilità di un disastro (e avessero evitato situazioni sfigatissime che non stanno a descrivere :-)

    Le situazioni sfigatissime purtroppo capitano, e non sempre sono prevedibili


    2) Avessero fatto un backup decente di AD ed Exchange invece di reinstallare tutto in un ambiente "simile" (e non sia mai che abbiano anche testato un restore prima del disastro)

    Io un test l'avevo fatto e aveva funzionato, per questo mi fidavo.
    Fare un backup decente che significa? Il backup integrato in un SBS2008, per esempio, non è una buona base di partenza? Se il report mi assicura che il backup è andato bene, perché non dovrei fidarmi?


    3) Invece di usare eseutil come fosse un'accetta leggessero la documentazione per capire quando serve e quando no. Voglio ribadire per la 500° volta che ESEUTIL /P NON SI DOVREBBE USARE MAI

    Ciao
    Gabriele

    Per quanto possa essere d'accordo con te in linea di principio, devo dire che la vita vera spesso differisce dal mondo ideale.
    Prendiamo il mio attuale caso (con cui sto ancora litigando): nel giro di due giorni si sono rotti due dischi su 3 e che, per qualche misteriosa ragione, il ripristino dal backup (che, stando al report giornaliero, veniva svolto regolarmente senza problemi) funzionava ma il sistema risultava inutilizzabile a causa di continui blocchi (mentre prima del guasto, funzionava regolarmente).

    Tu come ti saresti comportato, tenendo conto che il cliente, giustamente, pretendeva di riprendere il lavoro nel più breve tempo possibile?

    Io mi sono visto costretto a reinstallare in fretta e furia da zero il server per rimettere in piedi una struttura funzionante, rimandando ad un secondo tempo il recupero dei dati dal backup (i documenti e la posta erano comunque recuperabili velocemente). Mi è rimasta sul gobbo solo una cassetta postale perché l'utente in questione aveva disattivato la cache, ed è la cassetta che sto tentando di tirare fuori dal backup... finora con scarso successo.

    mercoledì 5 dicembre 2012 16:17
  • ---

    Io un test l'avevo fatto e aveva funzionato, per questo mi fidavo.
    Fare un backup decente che significa? Il backup integrato in un SBS2008, per esempio, non è una buona base di partenza? Se il report mi assicura che il backup è andato bene, perché non dovrei fidarmi?

    ---

    La mia definizione di backup decente non si riferisce al tool di backup. Si riferisce al fatto che il backup deve essere restorabile e testato regolarmente. Mi basterebbe un restore in un RSG di tanto in tanto.

    Un amico (molto saggio che lavora per una nota casa produttrice di programmi di backup) ha detto: "Il prodotto si chiama "*backup*" non "*restore*"" :-)

    L'attuale problema è dato dal fatto che il mailboxguid dell'utente non è identico a quello scritto nel DB. A naso mi verrebbe da dire che il restore di AD non è stato fatto per cui ti sei perso tutta la parte degli attributi Exchange e ci ritroviamo a dover provare ad editare a mano l'attributo per farli coincidere.

    Il cliente ti deve mettere nelle condizioni di poter lavorare. Per fare il lavoro bene ci vuole tempo.

    Come mi sarei comportato io è una bella domanda.
    Non lo so perchè tutti i clienti sono diversi.

    Questo può essere utile in base alla mia esperienza:

    1) Il cliente si deve mettere in testa che i miracoli non li facciamo

    2) Stabilire un Recovery Time Objective (In quanto tempo vuoi riavere il servizio) e un Recovery Point Objective (quanti dati ti puoi permettere di perdere) quando si mette in piedi la soluzione per evitare false aspettative.

    3) Specificare quali situazioni sono "coperte" dalla soluzione e quali no. I.e. Se togli il cached mode non posso garantire il restore dei dati. Tu hai garantito al cliente un determinato servizio in un determinato scenario. Se lui cambia le carte in tavola disabilitando la cache non si può aspettare che tu gli garantisca lo stesso servizio

    4) Il cliente deve capire bene la seguente affermazione: "Lo posso fare bene, veloce ed economico. Scegline 2"

    Sono convinto che tu abbia fatto il meglio possibile con quello che avevi a disposizione ma non sono le procedure ad essere farraginose.

    Se il cliente vuole l'alta affidabilità si fa una CCR o un LCR o un SCR come preferisci.
    Se tiene tutto sullo stesso server non c'è procedura che tenga. Se salta tutto il cliente aspetta.

    Se vai in giro su un monociclo e ti si buca la gomma non è colpa di chi ti ha venduto il monociclo o di chi lo ha costruito se non ti appare miracolosamente una nuova ruota in mano. Vuoi proteggerti in caso si buchi una gomma ? Ti compri la ruota di scorta, una bicicletta, una macchina, un jetpack, etc... fino a quando non sei soddisfatto.

    Lo so che la frase "spiegaglielo tu" balza alla mente ma ci deve essere un punto dove si mettono i puntini sulle i e i trattini sulle t.

    Ciao
    Gabriele

    P.S. Per quanto riguarda la vita vera

    1) Ore 3 AM: telefonata dal cliente

    2) Ore 6 AM: ho preso un aereo e sono andato a Barcellona

    3) Sono stato 50 (cinquanta) ore dal cliente a fargli tutti i replay dei log e restore del caso dormendo sui server

    4) Sono tornato a casa che mi sembrava di essere due persone diverse.

    5) Ripeti per 6 anni di reperibilità onsite su EMEA

    Ho ben chiara la vita vera :-)


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    mercoledì 5 dicembre 2012 19:14
  • Sembra che Gabriele Tansini [MSFT] abbia detto :

    ---

    Io un test l'avevo fatto e aveva funzionato, per questo mi fidavo.
    Fare un backup decente che significa? Il backup integrato in un SBS2008, per esempio, non è una buona base di partenza? Se il report mi assicura che il backup è andato bene, perché non dovrei fidarmi?

    ---

    La mia definizione di backup decente non si riferisce al tool di backup. Si riferisce al fatto che il backup deve essere restorabile e testato regolarmente. Mi basterebbe un restore in un RSG di tanto in tanto.

    Un amico (molto saggio che lavora per una nota casa produttrice di programmi di backup) ha detto: "Il prodotto si chiama "*backup*" non "*restore*"" :-)

    Ecco perché poi bisogna comprare altri prodotti... :-)


    L'attuale problema è dato dal fatto che il mailboxguid dell'utente non è identico a quello scritto nel DB. A naso mi verrebbe da dire che il restore di AD non è stato fatto per cui ti sei perso tutta la parte degli attributi Exchange e ci ritroviamo a dover provare ad editare a mano l'attributo per farli coincidere.

    Adesso sto facendo una copia del disco di backup, me lo porto a casa e provo a ripristinare l'intera immagine in una VM


    Il cliente ti deve mettere nelle condizioni di poter lavorare. Per fare il lavoro bene ci vuole tempo.

    Come mi sarei comportato io è una bella domanda.
    Non lo so perchè tutti i clienti sono diversi.

    Questo può essere utile in base alla mia esperienza:

    1) Il cliente si deve mettere in testa che i miracoli non li facciamo

    2) Stabilire un Recovery Time Objective (In quanto tempo vuoi riavere il servizio) e un Recovery Point Objective (quanti dati ti puoi permettere di perdere) quando si mette in piedi la soluzione per evitare false aspettative.

    3) Specificare quali situazioni sono "coperte" dalla soluzione e quali no. I.e. Se togli il cached mode non posso garantire il restore dei dati. Tu hai garantito al cliente un determinato servizio in un determinato scenario. Se lui cambia le carte in tavola disabilitando la cache non si può aspettare che tu gli garantisca lo stesso servizio

    Per fortuna non ho responsabilità "oggettive" (non c'era alcun accordo di garanzia, e ci mancherebbe) però mi spiacerebbe davvero dovergli dire che si è perso tutta la posta passata, anche perché un cliente deluso può sempre decidere di fartela pagare in altri modi (cambiare fornitore, per esempio).
    Il cliente medio pensa sempre che, sia pagando il massimo che pagando il minimo, il risultato sarà sempre impeccabile allo stesso modo, anche se gli si spiega chiaramente e cosa si può e cosa non si può fare con determinati budget.
    Ovviamente parlo del "cliente" in generale, non solo del mio caso specifico.


    4) Il cliente deve capire bene la seguente affermazione: "Lo posso fare bene, veloce ed economico. Scegline 2"

    Questa frase mi piace molto... mi sa che la adotterò.


    P.S. Per quanto riguarda la vita vera

    1) Ore 3 AM: telefonata dal cliente

    2) Ore 6 AM: ho preso un aereo e sono andato a Barcellona

    3) Sono stato 50 (cinquanta) ore dal cliente a fargli tutti i replay dei log e restore del caso dormendo sui server

    4) Sono tornato a casa che mi sembrava di essere due persone diverse.

    5) Ripeti per 6 anni di reperibilità onsite su EMEA

    Ho ben chiara la vita vera :-)

    E io che mi lamento... che dire: complimenti a te

    mercoledì 5 dicembre 2012 21:16
  • Ciao Ottobre,

    Non abbiamo ricevuto alcun aggiornamento e mi chiedevo se possiamo aiutarti ulteriormente o se il problema è stato risolto.

    Se così fosse ti saremmo grati di condividere il tuo feedback in questo spazio ricordandoti che altri membri della community potrebbero riscontrare comportamenti simili.

    Grazie in anticipo,


    Anca Popa Follow ForumTechNetIt on Twitter

    Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è” e non comporta alcuna responsabilità da parte dell'azienda. 

    lunedì 10 dicembre 2012 10:24
  • SCUSA!
    hai ragione non sono stato molto completo nel descrivere il problema :)
    Ma mi bastava provare a montare il DB nel recovery storage group in un mailbox store "normale" :)
    E ci sono riuscito!!! :)
    GRAZIE mille per l'aiuto!!!

    martedì 11 dicembre 2012 16:30