Exchange için Çevrimdışı Yedekleme ve Geri Yükleme Yordamları (Bu bağlantı, bir kısmı veya tamamı İngilizce olan içeriğe işaret edebilir.)

Makale çevirileri Makale çevirileri
Makale numarası: 296788 - Bu makalenin geçerli olduğu ürünleri görün.
Hepsini aç | Hepsini kapa

Bu Sayfada

Özet

Bu makalede, çevrimiçi yedekleme uygulama programlama arabirimleri (Apı) atlayacak ve el ile yedeklemek ve Exchange bilgi deposu veritabanlarının geri yüklemek için kullanabileceğiniz yöntemler anlatılmaktadır. Tek bir Exchange sunucusunda birden çok depolama grubu varsa, her bir depolama grubu bağımsız, kendi içinde bütünlük oluşturan bir birim çevrimdışı yedekleme ve geri yükleme amacıyla düşünülmesi gerekir.Çevrimdışı ve snapshot yedekleme hakkında ek bilgi için Microsoft Knowledge Base'deki makaleyi görüntülemek üzere aşağıdaki makale numarasını tıklatın:
296787XADM: Çevrimdışı yedekleme ve geri yükleme yordamları için Exchange Server 4.0, 5.0 ve 5.5

Daha fazla bilgi

Önce Başlat

Çevrimdışı olan bir yedekleme gerçekleştirmeden önce aşağıdaki bilgilere sahip olduğunuzdan emin olun:
  • Çevrimsel günlükler depolama grubu için etkin olup olmadığını belirleyin. (Çevrimsel günlükler varsayılan olarak Exchange devre dışıdır.) Çevrimsel günlükler etkin olup olmadığını belirlemek için <a0></a0>, Exchange System Manager'da storage_group nesnesinin özelliklerini açın ve sonra Genel sayfasını görüntüleyin. Çevrimsel günlükler devre dışı bırakmak için Çevrimli Günlük oluşturma onay kutusunu temizlemek için tıklatın. Çevrimsel günlükler değişiklikler depolama grubundaki her bir veritabanını durduruncaya kadar etkinleşmez.

    Çevrimdışı yedeklemeler gerçekleştirmeye döngüsel günlüğü devre dışı bırakmanız gerekmez. Ancak, işlem günlükleri geri yüklenen çevrimdışı yedekleri yeniden göndermek isterseniz, döngüsel günlüğü devre dışı olmalıdır.
  • Exchange veritabanı, akış, işlem günlüğü ve denetim noktası dosyaları için yol konumları ve günlük dosyası öneki depolama grubunu belirleyin.

    Bu bilgileri bulmak için <a0></a0>, Exchange System Manager'da storage_group nesnesinin özelliklerini açın ve sonra da Genel sayfasını görüntüleyin. Aşağıdaki üç kutu değerleri kaydı:
    • Günlük için dosya öneki (E0n E0n E00, E01 E02 ya da E03 olabilir)
    • Işlem günlüğü konumu (E0n*.log)
    • Sistem yolu konumu (E0n.chk)
    Veritabanı yolları, her <a0>database_name</a0> nesnesinin veritabanı özelliklerinde listelenir. Her veritabanı için aşağıdaki iki alan değerleri depolama grubundaki kaydı:
    • Exchange veritabanı (.edb)
    • Exchange Akış veritabanı (.stm)
Exchange System Manager'da kullanılamıyorsa, doğrudan ham özniteliklerini Active Directory'den ADSIEDIT veya LDIFDE gibi bir aracıyla okuyarak, önceki tüm bilgileri bulabilirsiniz. Tüm Exchange sunucularının Active Directory ormanı içinde bilgi ç?kt?s?n? almak, LDIFDE komutu aşağıdaki kullanabilirsiniz.

Not: Bu komut için metin için okunabilirlik bölünmüştür.
LDIFDE -F EXPATHS.TXT -D "CN = YAPıLANDıRMA, DC = configuration_container_domain, DC = top_level_domain =" -L MSEXCHESEPARAMLOGFILEPATH, MSEXCHESEPARAMSYSTEMPATH,
msexcheseparambasename, msexcheseparamcircularlog, msexchslvfile,
MSEXCHEDBFILE - R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Önceki komuttan çıktı örneği şudur:
D:\Exchsrvr\Mdbdata>ldifde -f con -d "cn = yapılandırma, dc = test, dc = com" -l msexch eseparamlogfilepath msexcheseparamsystempath, msexcheseparambasename, msexchesepar amcircularlog, msexchslvfile, msexchedbfile - r "(|(msexcheseparamlogfilepath=*) (ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) (msexchedbfi le=*)(msexcheseparamcircularlog=*))"
"Dc1.child.test.com için" bağlanılıyor
SSPI kullanılarak geçerli kullanıcı olarak oturum açılıyor
Dizin dosyası con için dışa aktarma
Girişler için aranıyor...

<çıkış > kesildi

.DN: CN = ilk depolama grubu, CN = ınformationstore, CN = Exchange1, CN = Servers, CN = First Administrative Group, CN = Administrative Groups, CN = Organization, CN = Microsoft Excha nge, CN = Services, CN = Configuration, DC = test, DC = = com
changeType: ekleme
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: CN Ortak bilgi deposu (EXCHANGE1), CN = ilk depolama grubu, CN = Informati onStore, CN = Exchange1, CN = Servers, CN = ilk yönetim grubu, CN = Administrative Groups, CN = kuruluş, CN = Microsoft Exchange, CN = Services, CN = Configuration, DC = = t sık kullanılan, DC = com
changeType: ekleme
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.DN: CN = özel bilgi deposu (Exchange1), CN = ilk depolama grubu, CN = Informat ionStore, CN = Exchange1, CN = Servers, CN = First Administrative Group, CN = Administrative Groups, CN = kuruluş, CN = Microsoft Exchange, CN = Services, CN = Configuration, DC = Te st, DC = com =
changeType: ekleme
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Başarıyla işlem günlüklerinin yeniden göndermeniz için <a0></a0>, hangi dosyaları yedeklenen aynı yolu konumlarına (.edb ve .stm) veritabanı dosyaları geri yüklemelisiniz. E:\Mdbdata klasörü ve F:\Mdbdata klasöründen akış veritabanı dosyası veritabanı dosyasını yedeklerseniz, örneğin, dosyaları E:\Mdbdata ve F:\Mdbdata, sırasıyla geri gerekir. Bu kısıtlama, veritabanı içinde (örneğin, bir tek bir posta kutusunu kurtarma durum) tümüyle farklı bir sunucuya geri yüklemek istediğiniz bile geçerlidir.

Bir veritabanı yolu, son yedeklemeden sonra değiştirirseniz, yalnızca kısmen işlem günlüklerinin yeniden ve yalnızca özgün konumuna geri yolunu değiştirirseniz, kısmi bir yeniden oynama elde edebilirsiniz. Eski yolu döner, değiştirilmiş olan yolu belirlenene günlükleri yeniden oynatabilirsiniz.

Işlem günlüğü dosyalarını (E0n*.log) farklı bir yol değerinden özgün yedek konumundan geri yükleyebilirsiniz. Bunun nedeni, işlem günlükleri, işlem günlüklerinin ilişik veritabanlarının konumlarını kaydetmek, ancak veritabanlarının işlem günlüklerinin konumlarını kaydetmek. Yeniden yürütme sırasında günlükleri "veritabanlarının hareket günlüğü üstbilgilerinde depolanan yol bilgileri kullanarak Bul". (Çevrimiçi yedekleme API, dahili veritabanı yolu değişiklikleri telafi eder ve böylece bu sınırlama uygulanmaz.)

Değil yedekleme veya denetim noktası dosyası (E0n.chk) geri yükleme, ancak bunu inceleyin veya kurtarma sırasında silmeniz gerekebilir, çünkü denetim noktası dosyası geçerli konumunu bilmeniz gerekir.

Exchange veritabanı dosyaları her için diğer nasıl ilişkilendirin

.Edb ve .stm tüm veritabanı bilgileri için bir son havuzları dosyalardır. Çoğu amacıyla tek bir dosya olarak farklıysa, bu iki dosyayı kabul; yedekleme ve geri bu dosyalarda iki kişilik. Bu dosyaları kronolojik olarak birbirleriyle eşitlenmiş kalması gerekir; bir gününde yedeklenmiş bir .edb dosyası başka bir günde yedeklenmiş bir akış dosyayla eşlenmesi edemiyor.

Exchange 2000 veya Exchange 2003 sunucusu depolama grupları'nı en çok dört destekleyebilir ve en çok beş veritabanlarının her depolama grubunu destekler. Bir işlem günlük dosyaları kümesini paylaşan veritabanlarının BIR depolama grubudur. Microsoft Exchange Server 5.5 en çok iki veritabanları (özel ve ortak bilgi depolarını) destekleyen bir depolama grubunu destekler.

Veritabanında değişiklik yapıldıkça, önce geçerli işlem günlüğü dosyasını ve ardından bir bellek içi önbellek değişiklikleri yazılır. Değişiklikleri önbellekte bulunan hemen sonra değişiklikleri kullanıcılara görünür duruma gelir. Bunu yapmak uygun olduğunda sayfa önbelleğinde veritabanı dosyasına temizlendi. Denetim noktası noktaya kadar olan tüm hareketleri fiziksel veritabanı dosyasına temizlendi günlük dosyasına sırayla işaretler. Geçerli günlük dosyası arkasında üç veya daha çok günlük dosyaları öteleme denetim noktası normaldir.

Önlemek için her depolama grubu, belirli bir depolama grubuna ait bir Exchange günlükleri için günlük dosyalarına ait olduğu hakkında karışıklığı dosya adının ilk üç karakterdir benzersiz günlük önek ile adlandırılması. Bir Exchange 2000 veya Exchange 2003 sunucu desteklenen dört depolama grubundan geçerli günlük öneklerinde E00 E01, E02 ve E03 ' dir. Bu makalede günlük önek için bir depolama grubu E0n belirlenmiştir. Geçerli günlük için bir depolama grubu her zaman E0n.log dosyadır.

Işlem günlüklerinin bir Tekdüzen 5 megabayt (MB boyutunda) olan. Geçerli günlük dosyası dolduğunda günlüğü oluşturma numarası, adı verilen ve onaltılık bir sıra numarasıyla yeniden adlandırılır ve yeni bir geçerli günlük dosyası oluşturulur. Günlük dosyalarının E0n00001.log, E0n00002.log vb. numaralanır. Bu makalede numaralı günlük dosyaları E0n xxxxx generically atanan. günlük.

Yeniden veritabanı anormal olarak durdurulmuş, denetim noktası dosyası (E0n.chk) kayıtlarının kurtarma başlaması gereken bir işlem günlüğü yürütme tutarlılık için veritabanını geri yüklemek. Bu işlem "yazılımla kurtarma." olarak adlandırılır "Çevrimiçi yedekleme geri yükleme sonrasında replayed günlük dosyaları işlemi olan sabit kurtarma," ile yazılımla kurtarma contrasted. Kurtarma, yazılım ve donanım arasındaki en önemli fark, enterpolasyon düzeltme eki dosya verilerini, günlük dosyası yeniden gönderme işlemine sabit kurtarma sırasında ' dir.

Tutarsız bir Exchange veritabanı dosyasını bir dosyaya olan tüm bekleyen işlemler için henüz yazılmış değil. Normal işlem sırasında henüz fiziksel olarak dosyasına yazılmadı önbelleğindeki bilgi olduğundan Exchange veritabanı dosyaları tutarsız. Genel olarak, bir Exchange veritabanı dosyası yalnızca bir normal kapatma veritabanı hizmetin sonra tutarlı düşünülebilir. Zamanından önce silinmiş gerekli günlük dosyaları yine de, (bilgileri işlem günlüklerinin ve veritabanı dosyalarını toplamı olarak dikkate) bir bütün olarak gerçekleştirilen veritabanı, her zaman tutarlı sürece.

Çevrimdışı bir Exchange veritabanı yedekleniyor

Çevrimdışı bir Exchange veritabanını yedeklemek için <a0></a0>:
  1. Yedeklemek istediğiniz veritabanı bağlantısını kesmek. Tüm veritabanlarının depolama grubu, yalnızca veritabanı veya yedeklemek istediğiniz veritabanı bağlantısını kesmek gerekmez.
  2. Veritabanı dosyaları (.edb hem .stm dosyası) tutarlı ve birbiriyle eşleşen olduğunu doğrulayın. Bunu yapmak için <a0></a0>, her dosyası aşağıdaki komutu çalıştırın:
    eseutil /mh veritabanı dosyası | <a1>/i</a1> "DB imzası" bulmak
    Not: Exchange 2000 Service Pack 2 ve daha sonra veritabanı durumunu "Tutarl?" veya "Inconsistent"; "Temiz kapatma" veya "Dirty kapanma." olarak bildirmez "Temiz kapatma" ne anlama geldiğini "Tutarl?" ile aynıdır ve "Dirty kapatma" ne anlama geldiğini "Inconsistent" ile aynıdır. Exchange 2000 Service Pack 2 veya daha sonra her veritabanı durumunu belirlemek için bu ek komutu çalıştırın:
    eseutil /mh veritabanı_adı | <a1>/i</a1> "Kapatma" bulmak
    Önceki komuttan çıktı örneği şudur:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    Yukarıdaki örnekte, VERITABANı imzalarının, hangi .edb ve .stm dosyaları için aynı kümeye ait olduğunu kanıtlar aynıdır. (Iki imza satır için bir imza eşleşme olarak kabul edilip birleştirilmez karakter karakter eşleşmesi gerekir.)

    Yalnızca VERITABANı imzaları eşleşmesi gerekir, ancak dosyalar da birbirleriyle eşitlenmiş ve tutarlı olmalıdır. Aşağıdaki komut dosyası her çalıştırın:
    eseutil /mh veritabanı dosyası | /i "tutarlı" bulmak
    Önceki komuttan neden çıktısı örneği şudur:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    Önceki örnekte, her iki dosya rapor "durumu: tutarlı." Onaltılık sayılar parantez (0x2CC7, 1F14, 1F7) her dosya için de aynı olmalıdır. Son tutarlı zaman damgası eşleşmesi gerekir. Bu, tutarlı ve birbiriyle eşleşen dosyalarıdır.

    Ya da raporlarını dosyalamak için "durumu: tutarsız" veya son tutarlı günlük pozisyonlar eşitlenmemiş, bu veritabanını temiz bir şekilde çıkarıldıktan. Bağlayın ve sonra da yeniden veritabanı bağlantısını kesmek. Dosyaları yine de doğru eşleşmiyor veya tutarsız daha fazla yardım için Microsoft Ürün Destek Hizmetleri'ne (PSS) başvurun.
  3. Her bir .edb veritabanı dosyası ve ilişkili .stm akış veritabanı dosyasını bir yedek konumuna kopyalayın.
  4. Yedeklenen veritabanlarını bağlayın.
  5. Çevrimsel günlükler etkinleştirilmişse, bu adımı atlayın. Çevrimsel günlükler devre dışı bırakılır ve "ileri daha sonra dönmek, <a0></a0>" istiyorsanız (E0n xxxxx .log dosyaları) numaralı işlem günlük dosyalarının tümünü yedeklemeniz gerekir. E0n.log Res1.log ve Res2.log dosyaların yedeğini değil.

    Bir günlük dosyası için E0n xxxxx .log E0n.log yeniden adlandırıldı sonra Exchange bu dosyayı yeniden değiştirmez için herhangi bir anda uygun bile hemen oluşturulduktan sonra numaralı günlük dosyaları yedekleyebilirsiniz. Ancak, yalnızca yönergelerini izleyerek, adım 6 günlük dosyaları Temizle yedeklendi.

    Günlük dosyası yedeklerinizi veritabanı yedekleri ile bire bir ilişkiyi yetkiniz yok. Her <a0>Günlük</a0> dosya yedekleme, günlük dosyalarının birkaç farklı veritabanı yedeklerinin herhangi karşı yürütülebilir olabilir zincirindeki bir bağlantıdır. Günlükleri veritabanının üstbilgisinin "Son tutarlı" satırında listelenen günlük başlayarak kablosunun bir akışı sahip olduğunuz sürece ileri belirli bir veritabanını yedekten geri dönebilirsiniz. Bu makalede, son tutarlı günlüğü için "düşük bağlantı günlük." adı verilir

    Önceki örneği başvurursanız, son tutarlı (0x2CC7, 1F14, 1F7) girdidir. Üç sayı, bu sayfaya bir günlük dosyası, bu günlük dosyası ve bir bayt uzaklığı bir sayfa belirleyin. Her günlük dosyası her 512 baytlık yaklaşık olarak 10.000 sayfaları içerir. Sayfa mahsup hesabı, ne günlük dosyasının tam (0x1F14 ondalık 7956 için eşdeğer günlük dosyası önceki örnekte yaklaşık yüzde 80 dolu olduğundan), gönderilmekte olan bir fikir verir, ancak kurtarma için ilgisizdir. Kurtarma, her zaman bir günlük dosyası başlangıcında başlar.

    Örneğin, düşük bağlantı E0n02cc7.log günlük dosyadır.

    Son tutarlı günlüğü hala E0n.log adlandırılabilir, çünkü, her zaman son tutarlı günlüğü disk üzerinde numaralı günlük göremeyebilirsiniz. Sıra numarası E0n.log sonunda veritabanı durdurulduğunda, günlük dosyasının üstbilgisi incelenerek verilecek görebilirsiniz (veritabanı çalışırken erişim E0n.log üstbilgiyi engellendi).

    Iç günlük oluşturma numarasını görüntülemek için <a0></a0>, aşağıdaki komutu çalıştırın:
    eseutil /ml [günlük dosyası] | <a1>/i</a1> "lGeneration" bulmak
    Önceki komuttan çıktı örneği şudur:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    Birçok durumda, günlük dosyası yedeklerinizi her bir veritabanı yedeklemesini iyi durumda olduğundan emin olarak daha iyi olduğundan emin olmak daha önemlidir. Bunun nedeni, her bir veritabanı yedeklemesini diğerleri için yedek sağlayabilir, ancak herhangi bir veritabanı yedeklemesini tam kurtarma her günlük dosyası koruma ilgili olarak bu yedeklemeden sonra bağlıdır olmasıdır.
  6. Çevrimsel günlükler etkinse, bu adımı atlayın. Güvenle kaldırılabilecek en yüksek numaralı günlük dosyasını belirlemek için denetim noktası dosyası üstbilgisi'ni inceleyin. Denetim noktası veritabanı anormal olarak durdurulmuş, Otomatik Kurtarma için gerekli en düşük numaralı günlük dosyasının izler. Denetim noktası dosyası incelemek için aşağıdaki komutu çalıştırın:
    Eseutil /mk E0n.chk
    Önceki komuttan çıktı örneği şudur:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    Üçüncü bir satır, denetim noktası satır (giriş çevrimiçi yedekleme kullanılır ve hiçbir zaman veritabanında çevrimiçi yedekleme gerçekleştirilirse, hepsi sıfırlardan kalır LastFullBackupCheckpoint) ilgili bilgileri içerir. Checkpoint günlük konumu biçimi <a0>veritabanı</a0> üstbilgisinde son tutarlı giriş ile aynıdır. Örneğin, denetim noktası içinde E0002cc7.log ' dir.

    Çevrimsel günlükler devre dışı bırakıldıysa, günlük dosyaları birikebilecek, kadar bunlar el ile silinmesi veya otomatik olarak çevrimiçi yedekleme işlemini tarafından kaldırıldı. Çevrimsel günlükler etkinleştirilmişse, yok, özel yönetim eski günlük dosyaları ise gerekli, denetim noktası bunları geçtikten sonra veritabanı hizmeti otomatik olarak eski günlük dosyalarını siler çünkü.

    Numaralı günlük dosyalarının tümünü yedekle sonra disk alanı tüm numaralı günlük dosyalarının en fazla kaldırma ancak denetim günlüğü dahil geri.

    ÖNEMLI: denetim günlüğü kaldırın.

    Örneğin, tüm günlükleri E0002cc6.log kadar kaldırabilirsiniz.
  7. Bu adım isteğe bağlıdır. Kopyalanan veritabanlarının sayfa düzeyinde bütünlüğünü doğrulamak için yer alan Esefile yardımcı programı'nı kullanabilirsiniz.

    Exchange Server 5.5 Service Pack 3 CD-ROM, Exchange 2000 Server yükleme CD-ROM'unu veya Exchange Server 2003 yükleme CD-ROM'unun Support klasöründeki Esefile.exe dosyası kullanılabilir. Microsoft PSS Esefile.exe dosya de edinebilirsiniz. .Edb dosyaları Exchange Server 5.0 ve 5.5, Exchange 2000 ve Exchange 2003'te bulunan Esefile yardımcı programı çalışır.

    Şu anda bir .stm dosyası her sayfası için sağlaması doğrulamak için çevrimiçi yedekleme dışında bir yöntem yoktur. .Stm dosyası ham veri içeriyor. Tüm dizinler ve verileri düzenlemek işaretçileri .edb dosyasında var. Veri kaybı olabilir, ancak mu belirli bazı istemci .stm dosyasında BIR sorun neden olan bir bütün olarak veritabanı yapısal ya da mantıksal bütünlüğünü tehlikeye.

    Bir Exchange veritabanı için sayfa sağlaması doğrulamak için <a0></a0>, yer alan Esefile yardımcı programı aşağıdaki komutu çalıştırın:
    Esefile /s database_name
    Önceki komuttan çıktı örneği şudur:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Başlatılmamış sayfa kabul edilir, ancak hiçbir sorun bir veritabanında vardır 0 hatalı sağlama toplamı ve 0 yanlış sayfa numaraları veya yanlış.

    Veritabanında yer alan Esefile yardımcı programı bütünlük denetimi başarılı olursa, en iyi emin olduğunuz iyi ve veritabanına ileri doğru kaydırmak için önceki bir yedekleme geri yükleme seçeneğidir. Bir yedekleme yoksa, onarmak veya veritabanı kurtarabilen hakkında öneriler için PSS'YE başvurun.
  8. Bu adım isteğe bağlıdır. Günlük dosyaları yedeklenen bütünlüğünü doğrulamak için aşağıdaki komutu kullanabilirsiniz:
    Eseutil /ml E0n
    Önceki komuttan çıktı örneği şudur:
    k:\backups>eseutil /ml E00
    							
    Bu komut, günlük dosyaları yedeklenen içeren klasörden çalıştırmalısınız. Bu komut geçerli çalışan Günlük klasörü karşı da çalıştırabilirsiniz, ancak Eseutil depolama grubundaki herhangi bir veritabanı çalışırken E0n.log üstbilgisinin okumaya çalışırsa, bir (JET_errFileAccessDenied)-1032 hatası alırsınız.

    Bu komut, günlük dosyalarında Bozulması algıladı ve aynı zamanda bir sıra ortasında bir günlük dosyası yoksa veya imza ile uyuşmuyor arasında herhangi bir günlük varsa uyarır.

Bir Exchange veritabanı çevrimdışı bir yedeği geri yükleniyor

Bu bölümde, çevrimdışı bir yedeği geri yüklemek için kullanabileceğiniz iki yöntem açıklanmaktadır:
  • "Süre işaretleyin" geri yükleme. Günlük dosyası, veritabanına replayed. Verileri yedeklemeden sonra oluşturulan tüm kaybolur.
  • Geri yükleme, "ileri geri". Yedeklemeden sonra oluşturulan günlük dosyalarını veritabanına çalınır. Tüm verileri yedeklemeden sonra oluşturulan tüm günlük dosyaları kullanılabiliyorsa, korunabilir. Çevrimsel günlükler etkinleştirilirse, "noktası zamandaki" Çevrimdışı yedekleme geri yükleme gerçekleştirmeniz gerekir; "ileri geri" geri yüklemeyi seçemezsiniz.
Dosya belirlenen geri en az aşağıdaki ölçütleri karşılamalıdır:
  • Zaman restorations nokta, tüm depolama grubundaki durdurulmuş veritabanlarının tutarlı olmalıdır ve bir geçerli denetim noktası dosyası olmalıdır. Geçerli denetim noktası dosyası veya varolan günlük dosyaları silmeyin.
  • Tekerleği ileri restorations tüm depolama grubundaki veritabanları durdurulmuş ve tutarlı olmalıdır ve tüm yedek alındığı saat sonra oluşturulan günlük dosyaları (geçerli E0n.log dahil) bulunması gerekir. Denetim noktası dosyası silinmelidir.
Dosya kümesi yukarıdaki koşulları karşılamıyorsa, geri yükleme ve yeniden gönderme değil her zaman başarısız olabilir, ancak yazılımla kurtarma sırasında-1216 bir hata iletisi (JET_errAttachedDatabaseMismatch) almak olasıdır.

Ilgili bir-1216 hatası

Ek yazılım kurtarma güvenlik önlemlerinin Exchange ile el ile oynanmış veri dosyalarını algılar ve geçerli veri kümesi ile çalışan bu kurtarma belirler, Exchange 2000 ve sonraki neden-1216 hata önceden kaybına neden var olan verileri.

Dosya kümesi tamamlanmadı, ancak başarılı bir yeniden oynama geçerli yönetici uyarı olmadan daha önceki Exchange sürümlerinde yazılımla kurtarma başlatır. Exchange 2000 ve daha sonra yönetici özellikle Eseutil kullanarak-1216 hata kılmalıdır.

Çevrimdışı olan bir yedekleme zamanı geri yükleme'de işaret

Bir çevrimdışı olan bir yedekleme zamanı geri yükleme'de yapmak için <a0></a0>:
  1. Geri yüklemek istediğiniz veritabanı şu anda bağlı, bağlantısını kesmek. Depolama grubundaki başka bir veritabanı çıkarıldıktan, bu veritabanları veritabanında ve akış (.edb ve .stm) dosyalarını her tutarlı ve eşleşen olması gerekir. (Tutarlılık ve eşleşen doğrulamak için <a0></a0>, adım 2'de, bu makalenin "Metatabanını yukarı bir Exchange veritabanı çevrimdışı" bölümüne bakın.)

    Tüm depolama grubundaki veritabanları çıkarıldıktan, tüm veritabanlarının tutarlı olması gerekir ve ayrıca, bir geçerli denetim noktası dosyası bulunmalıdır. Denetim noktası olarak E0n.log listeleyen bir başlığı olan herhangi bir depolama grubundaki veritabanları çalışmakta olan son kez kullanımda olan bir denetim noktası dosyası geçerli bir denetim noktası dosyasıdır. Herhangi bir veritabanı depolama grubundaki yine de bağlı ise, geçerli denetim noktası dosyası, sistem tarafından kullanılmakta denetim noktası dosyasıdır. Herhangi bir veritabanı depolama grubundaki çalıştırıyorsa, geçerli bir denetim noktası yok.

    Denetim noktası dosyası, tüm veritabanlarının durdurdu, doğrulamak için aşağıdaki komutları çalıştırın:
    eseutil /mk E0n.chk | Bul /i "Denetim"
    eseutil /ml E0n.log | Bul /i "lgeneration"
    Önceki komutlarının çıktısının bir örnek şudur:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Yukarıdaki örnekte, denetim noktası lGeneration 0x2cc7, biri ile günlüğüne; e00.log ise negatiftir. Bu nedenle, denetim noktası geçerli ele alınabilir.

    Denetim noktası geçerli değilse, herhangi bir veritabanı depolama grubundaki bağlamaya çalıştığınızda bir-1216 (JET_errAttachedDatabaseMismatch) hata iletisi alabilirsiniz. Tüm depolama grubundaki veritabanları tutarlı olsa bile bu sorun oluşabilir.
  2. Yedeklenen bir .edb ve .stm dosyaları için uygun bir veritabanında ve akış dosya konumları kopyalayın. (Bu konumları bulmak için <a0></a0>, bu makalenin "Before You Begin" bölümüne bakın.) Geri yüklenen dosyalar tutarlı ve eşleştirilmiş olduğundan emin olun.

    Not: önceden geri yüklemek istediğiniz veritabanı dosyalarının bir kopyasını sunucuda var, veritabanını geri yüklemeden önce var olan dosyaları başlatılabilir olmasa bile bu dosyaları yedekleme. Repairable olabilir; bu, hurda veri onlardan Exmerge yardımcı programını kullanarak olanağınız olabilir.
  3. Geri yüklenen veritabanı bağlayın. Veritabanının kendisi E0n.log dosyanın sonuna ekler. Sonra veritabanını başarıyla başlatıldı, önceden varolan günlük dosyası her zamankinden veritabanına replayed. Binlerce, hiyerarşideki klasörleri içeren ortak klasör veritabanları başlatmak için uzun zaman alabilir. Her 1000 klasörleri hiyerarşisindeki en az bir dakikadır olanak sağlar.

    Exchange Server önceki sürümlerinde, genellikle çalıştırmak için gereken ISINTEG - düzeltme eki dizini ile bilgi deposu veritabanını eşitlemek için bir bilgi deposu veritabanının bir çevrimdışı yedekleme geri sonra komut. Için düzeltme eki, Exchange veritabanında düzeltme eki sistem tarafından otomatik olarak yapılır, veritabanı olmadığı sürece farklı bir sunucuya geri depolama grubunu, mantıksal bir veritabanı nesnesini veya Active Directory nesnesi için veritabanına silindi ve Active Directory'de yeniden, gereklidir. Bu durumda, uygulama olay günlüğüne aşağıdaki hata iletisini günlüğe kaydedilir.
    Olay türü: hata
    Olay kaynağı: Msexchangeıs posta kutusu deposu
    Olay kategorisi: Genel
    Olay KIMLIĞI: 1087
    Tarihi: 5/4/2001
    Saat: 8:33:42 PM
    Kullanı.: Yok
    Bilgisayar: EXCHANGE1
    Açıklama: Bilgi deposu, çevrimdışı bir yedekten geri yüklendi. Microsoft Exchange System Manager'da, düzeltme, uygulanacak, veritabanının "ilk Depolama Grubu\Özel Bilgi deposu" için geri yüklenmesi için izin verildiğini gösterir.
    Bu sorunu gidermek için <a0></a0>, Bu veritabanı yazılmasını bir geri yükleme tarafından onay kutusunu Exchange Sistem Yöneticisi'nde <a0>veritabanı</a0> nesnesinin veritabanı özellikleri seçmek için tıklatmanız gerekir.

Çevrimdışı olan bir yedekleme ileri geri geri

En iyi tam başarı olasılığı için günlük dosyaları geri yüklenmiş bir veritabanına yeniden:
  • Tüm eski tam yedekleme saatten sonra oluşturulan işlem günlüklerinin kopyasını korur.
  • Bir veritabanı yolu, hemen sonra yeni bir tam yedekleme yapmadan değiştirmeyin.
  • ESEUTIL /p veya ESEUTIL /d hemen sonra yeni bir tam yedekleme yapmadan çalıştırmayın.
  • Ekleyip bir veritabanı bir depolama grubundaki hemen depolama grubundaki tüm veritabanlarının tam yedeklemesini yapmadan.
Geri yükleme işlemini başlatmak için <a0></a0>:
  1. Geri yüklemek istediğiniz veritabanına bağlı ise, kaldırma ve sunucu üzerindeki uygun yolları geri yüklemek istediğiniz veritabanı dosyalarını kopyalayın. Önceden geri yüklemek istediğiniz veritabanı dosyalarının bir kopyasını sunucuda varsa veritabanını geri yüklemeden önce var olan dosyaları başlatılabilir olmasa bile bu kopyalar yedekleyin. Dosyalar repairable olabilir ve onlardan hurda veri için Exmerge yardımcı programını kullanmak mümkün olabilir.
  2. Tüm depolama grubundaki veritabanları kaldırmak ve geçerli depolama grubundaki her bir veritabanı ve karşı her geri yüklenen veritabanı dosyası aşağıdaki komutu çalıştırın:
    eseutil /mh database_file_name | /i "tutarlı" bulmak
    Not: Exchange 2000 Service Pack 2 ve daha sonra veritabanı durumunu "Tutarl?" veya "Inconsistent" ancak "Temiz kapatma" veya "Dirty kapanma." olarak bildirmez "Temiz kapatma" ne anlama geldiğini "Tutarl?" ile aynıdır ve "Dirty kapatma" ne anlama geldiğini "Inconsistent" ile aynıdır. Exchange 2000 Service Pack 2 veya daha sonra her veritabanı durumunu belirlemek için bu ek komutu çalıştırın:
    eseutil /mh veritabanı_adı | <a1>/i</a1> "Kapatma" bulmak
    Önceki komuttan çıktı örneği şudur:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    Bu komut, üç amacı vardır:
    • Veritabanı dosyalarını her tutarlı olduğunu doğrulamak için <a0></a0>.
    • Her veritabanı için .edb ve .stm dosyaları için bir eşleşen çifti olduğunu doğrulamak için <a0></a0>.
    • Ilk ve son günlük dosyaları başarıyla-1216 bir hata oluşturmadan tüm verileri kurtarmak için gerekli olan en düşük ve yüksek bağlantı günlük dosyaları tanımlamak için <a0></a0>. Tüm veritabanları arasında en düşük son tutarlı değer düşük bağlantı günlüğü ve en son tutarlı yüksek bağlantı günlüğü değerdir.
    Önceki örnekte, düşük bağlantı günlük dosyası E0002ac8.log ve yüksek bağlantı günlük dosyası E0002cc7.log.
  3. Her bir veritabanı başlığına kaydedilen günlük imza düşük bağlantı günlüğü imzası olduğundan emin olun. Aşağıdaki komutları çalıştırın:
    eseutil /mh database_name | <a1>/i</a1> "Log imza" bulmak
    eseutil /ml low_anchor_log | <a1>/i</a1> "İmza" bulmak
    Önceki komuttan çıktı örneği şudur:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Bir günlük dosyası birden çok imza bildirebilir. Ilk imza, her zaman günlük dosyasının kendi imzası olan; diğer veritabanlarında, günlük dosyasının oluşturulduğu sırada çalışmakta olan. Yukarıdaki örnekte, veritabanı dosyaları kaydedilen günlük imzaları düşük bağlantı günlüğündeki günlük imza Bul.

    Düşük bağlantı günlüğü bulamazsanız, ileri günlükleri, bu veritabanına yürütemiyor. Düşük bağlantı günlük dosyasını bulamazsanız, tüm veritabanlarına tüm günlük dosyalarını yeniden kuramıyor. Eksik bir düşük bağlantı günlüğünü ile ilgilenme için kullanabileceğiniz iki yöntem vardır:
    • Tüm günlük dosyalarını kaldırabilirsiniz. Veritabanlarının tüm tutarlı olduğundan, herhangi bir günlük dosyalarının varlığını başlatabilirsiniz, ancak zaten veritabanı dosyaları değil, veri kurtarma sırasında herhangi bir şans kaybedersiniz.
    • Bir kablosunun günlük seriden düşük yüksek bağlantılarına oluşturmak ve Kurtarma üzerinde kalan veritabanlarını çalıştırın kadar veritabanlarını ve en düşük son tutarlı değerlerini kaldırabilirsiniz. Kaldırılan veritabanlarının depolama grubuna geri yerleştirdiğinizde, ek verileri bunlara yeniden kuramıyor.
  4. Yedeklemeyi yaptığınız sırada gibi geçerli veritabanı yolu konumları aynı olduğunu doğrulayın.

    Yedekleme yaptıktan sonra işlem günlük dosyası yolu veya çalışma yolu değiştirebilirsiniz, ancak veritabanı dosyalarını aynı yerlerde gelen yedeklenen bunlar, yalnızca günlük dosyası yeniden gerçekleştirebilirsiniz. Özgün konumlarını emin değilseniz, aşağıdaki komutu çalıştırın:
    eseutil /ml "Last_Consistent"_log | /i "database name or pattern"
    Önceki komuttan çıktı örneği şudur:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    Not: Düşük bağlantı günlüğü E0n00001.log ise, ilk veritabanını şimdiye kadar günlüğe bağlı olduğu için önce bir serideki ilk günlüğü üstbilgi üretmediğinden, kendi başlığında yol bilgisi yoktur. Bu durumda, veritabanı yolu bilgileri görüntülemek için sonraki günlüğün üstbilgisinde bakmak gerekir. Veritabanı günlüğü oluşturulduktan sonra günlük akışa bağlı oluşturulduğu veya nadiren de olsa, ayrıca ilk olandan, daha sonra günlükleri için doğru kaynaklanabilir.
  5. Tüm günlükleri, olarak kadar ileri kablosunun sıradaki olabildiğince düşük bir bağlantı numarasından toplamak ve bu günlükler, geçerli hareket günlüklerini yolunu kopyalayın. Sunucu üzerinde bir yerde bu ilk günlüklerini yedeklemeden bulunan günlükler üzerine yazılmaz. Bunu yapmak için <a0></a0>, birden çok yedekleme ortam türünden günlük dosyaları geri yüklemek gerekebilir.

    Önceki örnekte, düşük bağlantı E0002ac8.log ve yüksek bağlantı E0002cc7.log. Kullanılabilir günlüklerini inceleyin, bulabileceğiniz en yüksek numaralı günlük gerekli sayıda (örneğin, E0002cc6.log, 2cc7 yerine) bir sayı daha az olabilir. Bu, genellikle E0n.log henüz doldurulmuş ve, sıra numarası ile yeniden nedeniyle oluşur. E0n.log gerçekten yüksek bağlantı günlüğü olup olmadığını belirlemek için <a0></a0>, günlük dosyasının üstbilgisi lGeneration değeri incelemek için aşağıdaki komutu kullanmalısınız:
    eseutil /ml E0n.log | <a1>/i</a1> "lGeneration" bulmak
    Önceki komuttan çıktı örneği şudur:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Not: /mh anahtarı, Eseutil yardımcı programını kullanarak bir günlük dosyası başlığı görüntülemek için /ml anahtarını kullanın; bir veritabanı dosyası başlığı görüntülemek için kullanın. Anahtarlar yanıltır, komutların çıktısı yanlıştır.

    Genellikle, yüksek bağlantı günlüğü de en yüksek günlük, ancak bu doğru değil:
    • Günlük dosyalarının içinde bir olağanüstü durum yok.

      -VEYA-
    • Tümünü bir kerede depolama grubundaki veritabanları geri yüklüyorsunuz.
    Ilk örnekte,-1216 kurtarma işlemi sırasında hatalarla olasıdır; ikinci durumda, bunlar lGeneration sırasını devam sürece günlük dosyaları iletme, yüksek bağlantı günlüğü bile oynayabilirsiniz.
  6. Günlüklerin tümünün aynı günlük imza paylaşmak ve kablosunun sırayla olduğunu doğrulayın. Aşağıdaki komutu çalıştırın:
    eseutil /ml E0n > dosyaadı.txt
    Önceki komuttan çıktı örneği şudur:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Bu, Eseutil komutunu üç yaptıklarının: her günlük dosyası hasara karşı denetler günlük dosyası sıradaki herhangi bir boşluk bildirir ve günlük imza uyuşmazlığı algıladı.

    Tüm günlük imzaları yeniden aday olan tüm günlük dosyalarını arasında aynı olmalıdır. Yeniden başlamadan önce imzaları eşleşen olmayan tüm günlükleri kaldırmanız gerekir.

    Bu noktada, doğrulama sınamaları geçemediğini dosyaları kaldırdıktan sonra yalnızca işlem günlüğü dosyaları, işlem Logs klasöründe, dosyalar:
    • Düşük bağlantı günlük dosyası ile başlayan ve en yüksek bağlantı günlük dosyası, az devam kablosunun lGeneration sıralı ve ötesinde, olanaklıysa misiniz.
    • Günlük imzaları eşleştirme vardır.
  7. Yüksek bağlantı günlüğü zaten E0n.log adlı, dosyayı yeniden adlandırın.
  8. E0n.chk dosya sistemi yolu klasöründen kaldırın.

    Bir denetim noktası dosyası olmaması durumunda, Exchange Server günlüklerden işlem günlükleri klasöründe kullanılabilir en düşük numaralı günlük dosyasını yeniden başlar: Düşük bağlantı günlüğü. Exchange Server, E0n.chk dosyası varsa, bu dosyada kayıtlı olan denetim noktası oyunda başlar. Düşük bağlantı günlük E0n.chk gösteren, yeniden gönderme tamamen geri yüklenen dosya kümesi için başarısız olur. Denetim noktası dosyası ile bir hata yaparsanız, çoğu durumda, veritabanı dosyalarını yedekten geri yükleme üzerinden başlatmanız gerekir.
  9. Depolama grubunu'ı bağlamadan önce son bir denetimi olarak aşağıdakileri doğrulayın:
    • Tüm veritabanı dosyalarını, kendi çalışan yolları vardır.
    • Çalışan işlem günlük dosyası yolu yalnızca günlük dosyalarında düşük bağlantı günlükten başlatmak ve en az yüksek bağlantı günlüğü E0n.log adlı kullanılabilir en yüksek günlük ile devam dosyalarıdır.
    • Sistem yol klasöründe E0n.chk dosyası yok.
    Başarıyla depolama grubunu bağlayın ve bu dosya kümesiyle işlem günlüklerinin yeniden başlatmak için şimdi olmalıdır. Hatta Kurtarma tamamlandıktan ve veritabanı başladıktan sonra tüm günlük dosyalarının tüm verileri gerçekten oynatma sırasında karşılaşılan DB imzası ve yol sorunlar nedeniyle kurtarıldı değil. Bu makalenin "İlgilenen ile veritabanı imza ve yolu eşleşmiyor" bölümünde, bu sorunlar hakkında ek bilgi sağlar.
  10. Bilgi deposunun çalışır durumda değilse, başlatın ve sonra depolama grubundaki en az bir veritabanına bağlama. Bu yazılımla kurtarma depolama grubundaki veritabanları karşı çalışmasına neden olur.

    Exchange Server önceki sürümlerinde, genellikle çalıştırmak için gereken ISINTEG - düzeltme eki veritabanı dizini ile eşitlenecek çevrimdışı yedeğine bir bilgi deposu veritabanını geri yükledikten sonra komut. Için düzeltme eki, Exchange veritabanında düzeltme eki sistem tarafından otomatik olarak yapılır, veritabanı olmadığı sürece farklı bir sunucuya geri depolama grubunu, mantıksal bir veritabanı nesnesini veya Active Directory nesnesi için veritabanına silindi ve Active Directory'de yeniden, gereklidir. Bu durumda, uygulama olay günlüğüne aşağıdaki hata iletisini günlüğe kaydedilir.
    Olay türü: hata
    Olay kaynağı: Msexchangeıs posta kutusu deposu
    Olay kategorisi: Genel
    Olay KIMLIĞI: 1087
    Tarihi: 5/4/2001
    Saat: 8:33:42 PM
    Kullanı.: Yok
    Bilgisayar: EXCHANGE1
    Açıklama: Bilgi deposu, çevrimdışı bir yedekten geri yüklendi. Microsoft Exchange System Manager'da, düzeltme, uygulanacak, veritabanının "ilk Depolama Grubu\Özel Bilgi deposu" için geri yüklenmesi için izin verildiğini gösterir.
    Bu sorunu gidermek için <a0></a0>, Bu veritabanı yazılmasını bir geri yükleme tarafından onay kutusunu Exchange Sistem Yöneticisi'nde <a0>veritabanı</a0> nesnesinin veritabanı özellikleri seçmek için tıklatmanız gerekir.
Hataları ve veritabanını yeniden başlatıldığında oluşabilecek anomalies için Microsoft Windows NT olay görüntüleyicisinde uygulama olay günlüğüne bakın. Bir olay 301 replayed her günlük dosyası görüntülenir. Kurtarma işlemi sırasında hataları ve Uyarıları dikkatle izleyin.

Veritabanı imza ve yolu eşleşmiyor.

Veritabanlarının, günlük dosyalarını, kendi imzası olan ister. Ancak, günlük imzaları E0n000001.log dosyası oluşturulduktan sonra süreyi değiştirmek de veritabanının fiziksel topolojisi, günlük dosyaları ile izlenen değişiklikler olmadan değiştirilmediğinden her veritabanı imzaları değiştirme. DB imzası, çevrimdışı birleştirme ya da bir veritabanında Eseutil onarımı değiştirir. Böyle bir olayından sonra veritabanını önce aynı günlük akışı eklenebilir, ancak veritabanını, veritabanının önceki imzası olduğu sırada gerçekleştirilmiştir hareketleri yeniden kabul etmez. Veritabanını önceki bir kopyası, veritabanının imza değiştirildi sonra gerçekleştirilen hareket yeniden kabul etmez.

Veritabanı imzaları bu şekilde sıfırlanır olduğundan, çevrimdışı birleştirme ya da veritabanı onarma sonra hemen tam veritabanı yedekleri için önemle önerilir. Daha sonra eski imza ile veritabanının bir kopyasını geri, imza değişiklik noktaya kadar yeniden gönderme başarılı, ancak bu noktadan önceki tüm değişiklikleri kaybedersiniz.

Veritabanı yolları ortasında bir günlük akışı değiştirdiyseniz, efekt imzaları değiştirme benzer: yeniden noktasında değişikliği kesilir. (Çevrimiçi yedekleme API, yolları, kurtarma işlemi sırasında yeniden eşleştirmek için bir olanak sağlar; yedek alındığı bir yolu da değişmişse, bu nedenle çevrimiçi yedekleme API günlükleri tamamen oynatabilirsiniz.)

DB veya DB imzası sırasında yeniden gönderme, bu DB imzası veya VERITABANı yolu her günlük dosyası için 301 yeniden olaylarla satırı uygulama olay günlüğüne bildirilen sorunlar yol sorunlarla karşılaştı. Sorunun noktayı günlük dosyaları başarıyla çalmak için görünebilir, ancak bunun nedeni, yalnızca aynı uyuşmazlığı uyarı değil art arda kaydedilir. Genel kural olarak, belirli bir veritabanına yeniden gönderme, veritabanına başvuran ilk DB imzası veya yol hatayla karşılaştı noktasından kesildi.

Özellikler

Makale numarası: 296788 - Last Review: 3 Aralık 2007 Pazartesi - Gözden geçirme: 4.8
Bu makaledeki bilginin uygulandığı durum:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Anahtar Kelimeler: 
kbmt kbproductlink kberrmsg kbhowto KB296788 KbMttr
Machine-translated Article
ÖNEMLİ: Bu makale, bir kişi tarafından çevrilmek yerine, Microsoft makine-çevirisi yazılımı ile çevrilmiştir. Microsoft size hem kişiler tarafından çevrilmiş, hem de makine-çevrisi ile çevrilmiş makaleler sunar. Böylelikle, bilgi bankamızdaki tüm makalelere, kendi dilinizde ulaşmış olursunuz. Bununla birlikte, makine tarafından çevrilmiş makaleler mükemmel değildir. Bir yabancının sizin dilinizde konuşurken yapabileceği hatalar gibi, makale; kelime dağarcığı, söz dizim kuralları veya dil bilgisi açısından yanlışlar içerebilir. Microsoft, içeriğin yanlış çevrimi veya onun müşteri tarafından kullanımından doğan; kusur, hata veya zarardan sorumlu değildir. Microsoft ayrıca makine çevirisi yazılımını sıkça güncellemektedir.
Makalenin İngilizcesi aşağıdaki gibidir:296788

Geri Bildirim Ver

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com