การสำรองข้อมูลแบบออฟไลน์และกระบวนงานการคืนค่าสำหรับการแลกเปลี่ยน

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 296788 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

บทความนี้อธิบายวิธีที่คุณสามารถใช้เพื่อเลี่ยงผ่านโปรแกรมประยุกต์สำรองแบบออนไลน์ที่เขียนโปรแกรมอินเทอร์เฟซ (APIs) และด้วยตนเองสำรอง และคืนค่าฐานข้อมูลการเก็บข้อมูล Exchange ถ้าคุณมีกลุ่มการจัดเก็บหลายบนเซิร์ฟเวอร์ Exchange ที่หนึ่ง แต่ละกลุ่มการจัดเก็บข้อมูลต้องถูกจัดเป็นต่อหน่วยที่ขึ้นอยู่กับ self-contained สำหรับวัตถุประสงค์ของการสำรองข้อมูลแบบออฟไลน์และการคืนค่าสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการสำรองข้อมูลแบบออฟไลน์ และ snapshot คลิกหมายเลขบทความด้านล่างนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
296787XADM: การสำรองข้อมูลแบบออฟไลน์และกระบวนงานการคืนค่าสำหรับ Exchange Server 4.0, 5.0 และ 5.5

ข้อมูลเพิ่มเติม

ก่อนที่คุณเริ่มต้น

ก่อนที่จะทำการสำรองข้อมูลแบบออฟไลน์ ตรวจสอบให้แน่ใจว่า คุณมีข้อมูลต่อไปนี้:
  • กำหนดหรือไม่เข้าสู่ระบบแบบวงกลมจะเปิดใช้งานสำหรับกลุ่มการจัดเก็บ (เข้าสู่ระบบแบบวงกลมถูกปิดใช้งาน โดยค่าเริ่มต้นใน Exchange) การตรวจสอบ ว่าหรือไม่เข้าสู่ระบบแบบวงกลมถูกเปิดใช้งาน เปิดคุณสมบัติของstorage_groupวัตถุใน Exchange System Manager และจากนั้น ให้ดูทั่วไปหน้า เมื่อต้องการปิดใช้งานการเข้าสู่ระบบแบบวงกลม คลิกเพื่อยกเลิกการการบันทึกข้อมูลแบบวงกลมกล่องกาเครื่องหมาย การเปลี่ยนแปลงการเข้าสู่ระบบแบบวงกลมไม่มีผลจนกว่าคุณหยุดการแต่ละฐานข้อมูลในกลุ่มการจัดเก็บ

    คุณไม่จำเป็นต้องปิดการใช้งานการเข้าสู่ระบบแบบวงกลมเพื่อทำการสำรองข้อมูลแบบออฟไลน์ อย่างไรก็ตาม คุณต้องยกเลิกการหมุนเวียนบันทึกถ้าคุณต้องการ replay ธุรกรรมที่บันทึกไว้ในการคืนค่าการสำรองข้อมูลแบบออฟไลน์
  • ระบุตำแหน่งที่ตั้งของเส้นทางสำหรับฐานข้อมูล Exchange ของคุณ ส่งกระแสข้อมูล การ ล็อกธุรกรรม และจุดตรวจสอบแฟ้ม และอักขระเสริมหน้าแฟ้มบันทึกสำหรับกลุ่มการจัดเก็บ

    เมื่อต้องการค้นหาข้อมูลนี้ ให้เปิดคุณสมบัติของstorage_groupวัตถุใน Exchange System Manager และจากนั้น ให้ดูทั่วไปหน้า บันทึกค่าสำหรับกล่องการสามแบบต่อไปนี้:
    • หมายเลขนำหน้าแฟ้มบันทึก(E0n ซึ่ง E0n อาจ E00, E01, E02 หรือ E03)
    • ตำแหน่งที่ตั้งล็อกของธุรกรรม(E0n*.log)
    • ตำแหน่งที่ตั้งของเส้นทางระบบ(E0n.chk)
    แสดงในคุณสมบัติของฐานข้อมูลของแต่ละเส้นทางฐานข้อมูลdatabase_nameวัตถุ บันทึกค่าสำหรับสองฟิลด์ต่อไปนี้สำหรับแต่ละฐานข้อมูลในกลุ่มการจัดเก็บ:
    • ฐานข้อมูล exchange(.edb)
    • การแลกเปลี่ยนฐานข้อมูลแบบกระแสข้อมูล(.stm)
ถ้า Exchange System Manager ไม่พร้อมใช้งาน คุณสามารถค้นหาข้อมูลก่อนหน้านี้ทั้งหมดได้ โดยการอ่านแอตทริบิวต์ raw ด้วยเครื่องมือเช่น ADSIEDIT หรือ LDIFDE จาก Active Directory โดยตรง คุณสามารถใช้คำสั่ง LDIFDE ต่อไปนี้จะแสดงผลข้อมูลสำหรับเซิร์ฟเวอร์ Exchange ในฟอเรสต์มีไดเรกทอรีที่ใช้งานอยู่ทั้งหมด

หมายเหตุ:: แบบข้อความสำหรับคำสั่งนี้ได้ถูกห่อสำหรับ readability
ldifde -f expaths.txt -d " cn =การตั้งค่าคอนฟิก dc =configuration_container_domain, dc =top_level_domain"-l msexcheseparamlogfilepath, msexcheseparamsystempath
msexchslvfile msexcheseparambasename, msexcheseparamcircularlog
msexchedbfile - r"(|(msexcheseparamlogfilepath=*)(msexcheseparamsystempath=*)(msexcheseparambasename=*)(msexcheseparamcircularlog=*)(msexchedbfile=*)(msexchslvfile=*))"
ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
D:\exchsrvr\mdbdata>ldifde -f con -ว " cn =การตั้งค่าคอนฟิก dc =ทดสอบ dc = com "-l msexch eseparamlogfilepath, msexcheseparamsystempath, msexcheseparambasename, msexchesepar amcircularlog, msexchslvfile, msexchedbfile - r" (|(msexcheseparamlogfilepath=*) (มิลลิวินาที excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) (msexchedbfi le=*)(msexcheseparamcircularlog=*))"
การเชื่อมต่อกับ "dc1.child.test.com"
เข้าสู่ระบบในฐานะผู้ใช้ปัจจุบันใช้ SSPI
การส่งออกการไดเรกทอรี con แฟ้ม
ค้นหารายการ...

<output truncated=""></output>

.dn: CN = กลุ่มที่เก็บแรก CN = InformationStore, CN = Exchange1, CN =เซิร์ฟเวอร์ CN = กลุ่มระดับผู้ดูแลแรก CN =กลุ่มระดับผู้ดูแล CN =องค์กร CN = nge Microsoft Excha, CN =บริการ CN =การตั้งค่าคอนฟิก DC =ทดสอบ DC = com
changetype: เพิ่ม
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN =ที่เก็บข้อมูลสาธารณะ (EXCHANGE1), CN = กลุ่มที่เก็บแรก CN = onStore Informati, CN = Exchange1, CN =เซิร์ฟเวอร์ CN = กลุ่มระดับผู้ดูแลแรก CN =กลุ่มระดับผู้ดูแล CN =องค์กร CN = Microsoft Exchange, CN =บริการ CN =การตั้งค่าคอนฟิก DC = Tes t, DC = com
changetype: เพิ่ม
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN =ที่เก็บข้อมูลส่วนตัว (Exchange1), CN = กลุ่มที่เก็บแรก CN = ionStore Informat, CN = Exchange1, CN =เซิร์ฟเวอร์ CN = กลุ่มระดับผู้ดูแลแรก CN =กลุ่มระดับผู้ดูแล CN =องค์กร CN = Microsoft Exchange, CN =บริการ CN =การตั้งค่าคอนฟิก DC = st โท DC = com
changetype: เพิ่ม
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
การล็อกธุรกรรมที่ replay เสร็จเรียบร้อยแล้ว คุณต้องคืนค่าแฟ้มฐานข้อมูล (.edb และ.stm) ไปยังตำแหน่งต่าง ๆ เส้นทางเดียวกันที่ใช้ที่แฟ้มถูกสำรอง ตัวอย่างเช่น ถ้าคุณสำรองแฟ้มฐานข้อมูลจากโฟลเดอร์ E:\Mdbdata และแฟ้มฐานข้อมูลแบบกระแสข้อมูลจากโฟลเดอร์ F:\Mdbdata คุณต้องคืนแฟ้ม E:\Mdbdata และ F:\Mdbdata ตามลำดับ ข้อจำกัดนี้ใช้แม้ว่าคุณต้องการคืนค่าฐานข้อมูลไปยังเซิร์ฟเวอร์ที่แตกต่างกันทั้งหมด (ตัวอย่างเช่น ในสถานการณ์การกู้คืนของกล่องจดหมายเดียว)

ถ้าคุณเปลี่ยนเส้นทางของฐานข้อมูลหลังการสำรองข้อมูลล่าสุด คุณสามารถเพียงบางส่วน replay ล็อกธุรกรรม และคุณสามารถรับ replay เป็นบางส่วนเท่านั้นถ้าคุณเปลี่ยนเส้นทางไปยังตำแหน่งเดิม ถ้าคุณแปลงกลับไปยังเส้นทางเดิม คุณสามารถ replay บันทึกจนถึงจุดถูกเปลี่ยนเส้นทาง

คุณสามารถคืนค่าแฟ้มล็อกธุรกรรม (E0n*.log) ไปยังเส้นทางอื่นนอกเหนือจากตำแหน่งที่สำรองข้อมูลต้นฉบับ นี่คือเนื่องจากตำแหน่งที่ตั้งของฐานข้อมูลที่ล็อกธุรกรรมแนบอยู่กับบันทึกล็อกธุรกรรม แต่ฐานข้อมูลไม่บันทึกตำแหน่งที่ตั้งของไฟล์บันทึกของธุรกรรม ในระหว่างการ replay ล็อก "หา" ฐานข้อมูล โดยใช้เส้นทางข้อมูลที่เก็บไว้ในหัวข้อการล็อกธุรกรรม (The online backup API compensates internally for database path changes, and so this limitation does not apply.)

You do not back up or restore the checkpoint file (E0n.chk), but you must know the current location of the checkpoint file because you may need to examine it or delete it during recovery.

How Exchange Database Files Relate to Each Other

The .edb and .stm files are the final repositories for all database information. For most purposes, treat these two files as if they are a single file; back up and restore these files in tandem. These files must stay synchronized chronologically with each other; an .edb file that is backed up on one day cannot be matched with a streaming file that is backed up on another day.

An Exchange 2000 or an Exchange 2003 server can support up to four storage groups, and each storage group can support up to five databases. A storage group is a set of databases that share a common set of transaction log files. Microsoft Exchange Server 5.5 can support a maximum of one storage group, which supports up to two databases (the private and public information stores).

As changes are made to the database, the changes are first written to the current transaction log file, and then to an in-memory cache. As soon as changes are present in the cache, those changes become visible to users. Pages in the cache are flushed to the database file when it is convenient to do so. The checkpoint marks the point in the log file sequence up to which all transactions have been physically flushed to the database file. It is normal for the checkpoint to lag three or more log files behind the current log file.

To avoid confusion about which log files belong to each storage group, Exchange logs that belong to a given storage group are named with a unique log prefix, which is the first three characters of the file name. Valid log prefixes for the four storage groups that are supported on an Exchange 2000 or Exchange 2003 server are E00, E01, E02, and E03. Throughout this article, the log prefix for a storage group is designated as E0n. The current log file for a storage group is always E0n.log.

Transaction logs are a uniform 5 megabytes (MBs) in size. When the current log file is full, it is renamed with a hexadecimal sequence number, called the log generation number, and a new current log file is generated. Log files are numbered as E0n00001.log, E0n00002.log, and so on. Throughout this article, numbered log files are designated generically as E0nxxxxx.log.

ถ้าฐานข้อมูลหยุดอย่างผิดปกติ เร็กคอร์ดที่จุดตรวจสอบ (E0n.chk) ของแฟ้มล็อกธุรกรรมที่การกู้คืนต้องเริ่ม replay เพื่อคืนค่าฐานข้อมูลความสอดคล้องกัน กระบวนการนี้เรียกว่า "กู้คืนข้อมูลนุ่มนวล" การกู้คืนนุ่มนวลสามารถถูก contrasted กับการกู้คืน "ฮาร์ข้อมูล ซึ่งเป็นกระบวนการ โดยที่บันทึกแฟ้มเป็น replayed หลังการคืนค่าของการสำรองข้อมูลแบบออนไลน์ ความแตกต่างที่สำคัญระหว่างการกู้คืนนุ่ม และฮาร์ดดิสก์อยู่ที่ interpolation ของโปรแกรมปรับปรุงไฟล์ข้อมูลลงใน replay กระบวนการบันทึกแฟ้มในระหว่างการกู้คืนฮาร์

แฟ้มฐานข้อมูล Exchange ที่สอดคล้องกันเป็นแฟ้มว่า ธุรกรรมที่ค้างชำระทั้งหมดได้ไม่ถูกเขียนไปยัง ในระหว่างการดำเนินการปกติ แฟ้มฐานข้อมูล Exchange ได้ไม่สอดคล้องกันเนื่องจากมีข้อมูลในแคชที่ยังไม่ได้ถูกทางกายภาพเขียนไปยังแฟ้ม โดยทั่วไป แฟ้มฐานข้อมูลการแลกเปลี่ยนสามารถจะถือว่าความสอดคล้องกันเท่านั้นหลังจากการปิดการทำงานปกติของเซอร์วิสฐานข้อมูล nonetheless ฐานข้อมูล ดำเนินการเป็นแบบเต็ม (ถือเป็นผลรวมของข้อมูลในทั้งธุรกรรมที่บันทึกและแฟ้มฐานข้อมูล), ได้ตลอดเวลาความสอดคล้องกันจนกว่าแฟ้มบันทึกที่จำเป็นจะถูกลบก่อนกำหนด

การสำรองข้อมูลในฐานข้อมูล Exchange แบบออฟไลน์

การสำรองข้อมูลในฐานข้อมูล Exchange แบบออฟไลน์:
  1. dismount ฐานข้อมูลที่คุณต้องการสำรองข้อมูล คุณไม่จำเป็นต้อง dismount ฐานข้อมูลในกลุ่มการจัดเก็บ เพียงฐานข้อมูลหรือฐานข้อมูลที่คุณต้องการสำรองข้อมูลทั้งหมด
  2. ตรวจสอบว่า แฟ้มฐานข้อมูล (แฟ้มทั้ง.edb และ.stm) จะสอดคล้องกัน และตรงกัน เมื่อต้องการทำเช่นนั้น เรียกใช้คำสั่งต่อไปนี้กับแต่ละแฟ้ม:
    แฟ้มฐานข้อมูล /mh eseutil | ค้นหา /i "ลายเซ็นของฐานข้อมูล"
    หมายเหตุ:: Exchange 2000 Service Pack 2 และรุ่นที่ใหม่กว่าไม่รายงานสถานะของฐานข้อมูล เป็น "Consistent" หรือ "Inconsistent" แต่ เป็น "ใหม่ทั้งหมดปิดระบบ" หรือ "สกปรกปิด ความหมายของ "ใหม่ทั้งหมดปิดระบบ" จะเหมือนกับ "Consistent" และความหมายของ "สกปรกปิดเครื่อง" จะเหมือนกับ "Inconsistent" สำหรับ Exchange 2000 Service Pack 2 หรือในภาย หลัง เรียกใช้คำสั่งนี้เพิ่มเติมเพื่อตรวจสอบสถานะของแต่ละฐานข้อมูล:
    eseutil /mh database_name | ค้นหา /i "ปิดเครื่อง"
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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:
    							
    ในตัวอย่างก่อนหน้านี้ ลายเซ็นของฐานข้อมูลเป็นแบบเดียวกัน ซึ่ง proves ว่า แฟ้ม.edb และ.stm เป็นของชุดเดียวกัน (ทั้งสองบรรทัดลายเซ็นต้องตรงกับอักขระสำหรับอักขระใน entirety ของพวกเขาจะถือว่าเป็นลายเซ็นที่ตรงกัน)

    ไม่เดียวต้องตรงกับการลายเซ็นของฐานข้อมูล แต่แฟ้มจะต้องทำข้อมูลให้ตรงกัน และความสอดคล้องกัน เรียกใช้คำสั่งต่อไปนี้สำหรับแต่ละแฟ้ม:
    แฟ้มฐานข้อมูล /mh eseutil | ค้นหา /i "สอดคล้องกัน"
    ต่อไปนี้เป็นตัวอย่างของผลลัพธ์ที่เป็นผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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
    							
    ในตัวอย่างก่อนหน้านี้ ทั้งสองรายงานแฟ้ม "สถานะ: สอดคล้องกัน" หมายเลขฐานสิบหกในวงเล็บสำหรับแต่ละแฟ้ม (0x2CC7, 1F14, 1F7) ต้องตรงกันด้วย ประทับเวลาที่สอดคล้องกันครั้งล่าสุดไม่จำเป็นต้องตรงกัน แฟ้มเหล่านี้มีทั้งความสอดคล้องกัน และตรงกัน

    ถ้าเป็นแฟ้มรายงาน "สถานะ: ไม่สอดคล้อง" หรือไม่มีการซิงโครไนส์บันทึกตำแหน่งงานที่สอดคล้องกันครั้งล่าสุด ฐานข้อมูลถูกไม่ dismounted cleanly กำหนดใช้ และจากนั้น dismount ฐานข้อมูลอีกครั้ง ถ้าแฟ้มไม่ตรงกันได้อย่างถูกต้องยังคง หรือไม่สอดคล้องกัน ติดต่อบริการสนับสนุนผลิตภัณฑ์ของ Microsoft (PSS) เพื่อขอความช่วยเหลือเพิ่มเติม
  3. คัดลอกแต่ละแฟ้มฐานข้อมูล.edb และสอดคล้องกัน.stm แบบกระแสข้อมูลแฟ้มฐานข้อมูลไปยังตำแหน่งที่ตั้งข้อมูลสำรอง
  4. กำหนดใช้ที่ backed อัพฐานข้อมูล
  5. ถ้ามีการเปิดใช้การเข้าสู่ระบบแบบวงกลม ข้ามขั้นตอนนี้ ถ้าปิดใช้งานการบันทึกแบบวงกลม และคุณต้องการ "หมุนไปข้างหน้า" ในภายหลัง คุณต้องสำรองแฟ้มล็อกธุรกรรมที่มีหมายเลข (หมาย E0n ทั้งหมดxxxxx.log แฟ้ม) ไม่สำรองแฟ้ม E0n.log, Res1.log และ Res2.log

    คุณสามารถสำรองแฟ้มบันทึกที่มีหมายเลขตลอดเวลาสะดวก ทันทีแม้หลังจากสร้าง เพราะหลังจากที่แฟ้มบันทึกได้ถูกเปลี่ยนชื่อจาก E0n.log เพื่อ E0nxxxxxเปลี่ยน.log, Exchange ไม่แปลงแฟ้มนั้นอีกครั้ง อย่างไรก็ตาม กำจัดสำรองแฟ้มบันทึกเฉพาะตามที่แนะนำในขั้นตอนที่ 6

    สำรองข้อมูลแฟ้มบันทึกของคุณไม่ได้เป็นการโต้ตอบที่ one-to-one กับสำเนาสำรองของฐานข้อมูลของคุณ แต่ละการสำรองข้อมูลแฟ้มบันทึกถูกเชื่อมโยงในกลุ่มของแฟ้มบันทึกที่อาจ playable กับสำเนาสำรองของฐานข้อมูลที่แตกต่างกันหลายใด ๆ คุณสามารถย้อนไปข้างหน้าจากสำเนาสำรองฐานข้อมูลที่เฉพาะตราบเท่าที่คุณมีการสตรีม unbroken ของบันทึกที่มีการเริ่มการทำงานกับแฟ้มบันทึกที่ระบุไว้ในบรรทัดที่ "สอดคล้องล่าสุดกัน" ของหัวข้อของฐานข้อมูล ในบทความนี้ แฟ้มบันทึกที่สอดคล้องกันครั้งล่าสุดถูกเรียกว่า "ยึดต่ำล็อก

    ถ้าคุณดูตัวอย่างก่อนหน้านี้ รายการสุดท้ายที่สอดคล้องกันเป็น (0x2CC7, 1F14, 1F7) หมายเลขสามกำหนดล็อกไฟล์ หน้าในล็อกไฟล์นั้น และออฟเซตของไบต์เป็นหน้านั้น แต่ละแฟ้มล็อกประกอบด้วยประมาณ 10000 หน้า 512 ไบต์แต่ละ The page offset gives you a good idea of how close the log file is to being full (the log file in the preceding example is about 80 percent full, because 0x1F14 is equivalent to decimal 7956), but is irrelevant to recovery. Recovery always starts at the beginning of a log file.

    In this example, the low anchor log file is E0n02cc7.log.

    You may not always see the last consistent log on disk as a numbered log, because the last consistent log may still be named E0n.log. You can see the sequence number E0n.log will eventually be given by examining the log file header while the database is stopped (access is denied to the E0n.log header while the database is running).

    To view the internal log generation number, run the following command:
    eseutil /ml [log file] | find /i "lGeneration"
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    In many circumstances, it is more important to make sure that your log file backups are good than it is to make sure that each database backup is good. This is because each database backup can provide redundancy for the others, but full recovery from any database backup is dependent on the preservation of each and every log file after that backup.
  6. Skip this step if circular logging is enabled. Examine the header of the checkpoint file to determine the highest numbered log file that can be safely removed. The checkpoint tracks the lowest numbered log file that is necessary for automatic recovery if the database is abnormally stopped. To examine the checkpoint file, run the following command:
    eseutil /mk E0n.chk
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    The third line, the Checkpoint line, contains the relevant information (the LastFullBackupCheckpoint entry is used by online backup, and remains all zeroes if an online backup is never performed against the database). The Checkpoint log position format is the same as the last consistent entry in the database header. In this example, the checkpoint is in E0002cc7.log.

    If circular logging is disabled, log files accumulate until they are either manually deleted or removed automatically by the online backup process. If circular logging is enabled, no special management of old log files is required, because the database service automatically deletes old log files after the checkpoint passes through them.

    After you back up all of the numbered log files, you can reclaim disk space by removing all of the numbered log files up to, but not including, the checkpoint log.

    สิ่งสำคัญ: Do not remove the checkpoint log.

    In this example, you can remove all of the logs up to E0002cc6.log.
  7. This step is optional. You can use the Esefile utility to verify the page-level integrity of the copied databases.

    The Esefile.exe file is available in the Support folder on the Exchange Server 5.5 Service Pack 3 CD-ROM, the Exchange 2000 Server installation CD-ROM, or the Exchange Server 2003 installation CD-ROM. You can also obtain the Esefile.exe file from Microsoft PSS. The Esefile utility works for .edb files from Exchange Server 5.0 and 5.5, Exchange 2000, and Exchange 2003.

    There is currently no method other than online backup to verify the checksums for each page of an .stm file. The .stm file contains raw data. All of the indexes and pointers that organize that data are in the .edb file. A problem in the .stm file causes some specific client data loss, but does not compromise the structural or logical integrity of the database as a whole.

    To verify the page checksums for an Exchange database, run the following Esefile utility command:
    esefile /sdatabase_name
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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
    							
    Uninitialized pages are acceptable, but in a database with no problems, there are 0 bad checksums and 0 wrong page numbers.

    If a database does not pass the Esefile utility integrity check, your best option is to restore an earlier backup that you know to be good, and to roll the database forward. If such a backup is not available, consult PSS for advice about how to repair or salvage the database.
  8. This step is optional. You can use the following command to verify the integrity of backed up log files:
    eseutil /ml E0n
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    k:\backups>eseutil /ml E00
    							
    คุณต้องเรียกใช้คำสั่งนี้ได้จากโฟลเดอร์ที่ประกอบด้วยการ backed สำรองแฟ้มบันทึก คุณสามารถเรียกใช้คำสั่งนี้ได้เช่นกันจากโฟลเดอร์แฟ้มบันทึกที่กำลังทำงานปัจจุบัน แต่หาก Eseutil พยายามที่จะอ่านหัวข้อของ E0n.log ในขณะที่ฐานข้อมูลใด ๆ ในกลุ่มการจัดเก็บข้อมูลกำลังทำงานอยู่ คุณได้รับข้อผิดพลาด-1032 (JET_errFileAccessDenied)

    คำสั่งนี้ตรวจพบความเสียหายในแฟ้มบันทึก และจะ เตือนคุณ ถ้าแฟ้มบันทึกไม่พบในระหว่างการลำดับ หรือ ถ้าลายเซ็นที่ไม่ตรงกันอยู่ในระหว่างการล็อกไฟล์

การคืนค่าการสำรองข้อมูลแบบออฟไลน์ของฐานข้อมูลการแลกเปลี่ยน

ส่วนนี้อธิบายวิธีการสองวิธีการคืนค่าการสำรองข้อมูลแบบออฟไลน์:
  • คืนค่า "ชี้เวลา" ไม่มีแฟ้มบันทึกถูก replayed ลงในฐานข้อมูล ข้อมูลที่สร้างขึ้นหลังจากการสำรองข้อมูลทั้งหมดจะสูญหายไป
  • คืนค่า "ย้อนไปข้างหน้า" แฟ้มบันทึกที่ถูกสร้างขึ้นหลังจากการสำรองข้อมูลจะเล่นลงในฐานข้อมูล ถ้าแฟ้มบันทึกทั้งหมดพร้อมใช้งาน ข้อมูลที่ถูกสร้างขึ้นหลังจากการสำรองข้อมูลทั้งหมดสามารถถูกรักษาไว้ ถ้ามีการเปิดใช้การเข้าสู่ระบบแบบวงกลม คุณต้องดำเนินการคืนค่า "จุดเวลา" ของการสำรองข้อมูลแบบออฟไลน์ของคุณ คุณไม่สามารถเลือกการคืนค่า "ย้อนไปข้างหน้า"
ชุดของแฟ้มที่คุณคืนค่าต้องเป็นไปตามเกณฑ์ที่น้อยที่สุดต่อไปนี้:
  • สำหรับจุดในเวลา restorations ฐานข้อมูลถูกหยุดในกลุ่มการจัดเก็บข้อมูลทั้งหมดต้องมีความสอดคล้องกัน แล้วต้องมีแฟ้มจุดตรวจสอบที่ถูกต้อง ไม่ต้องลบจุดตรวจสอบแฟ้มปัจจุบันหรือล็อกไฟล์ใด ๆ
  • สำหรับการโร restorations ไปข้างหน้า ฐานข้อมูลในกลุ่มการจัดเก็บข้อมูลทั้งหมดต้องถูกหยุด และความสอดคล้องกัน และแฟ้มล็อกที่ถูกสร้างขึ้นหลังจากเวลาที่ดำเนินการสำรองข้อมูล ทั้งหมดต้องมีอยู่ (ซึ่งรวมถึง E0n.log ที่ปัจจุบัน) ต้องลบแฟ้มจุดตรวจสอบ
ถ้าชุดของแฟ้มไม่ตรงกับเงื่อนไขที่ก่อนหน้านี้ replay และการคืนค่าอาจไม่จำเป็นต้องไม่ แต่คุณก็น่าจะได้รับข้อความข้อผิดพลาด-1216 (JET_errAttachedDatabaseMismatch) ในระหว่างการกู้คืนนุ่มนวล

จัดการกับข้อผิดพลาดของ-1216

คุณสมบัติการกู้คืนเพิ่มเติมที่นุ่มนวลใน Exchange 2000 และรุ่นที่ใหม่กว่าสาเหตุ-1216 ผิดพลาดเมื่อตรวจพบแฟ้มข้อมูลที่ได้ถูกเปลี่ยนแปลงด้วยตนเอง Exchange และกำหนดว่าการกู้คืนข้อมูลที่กำลังทำงานกับชุดข้อมูลปัจจุบันจะทำขาดก่อนหน้านี้ให้ข้อมูลที่มีอยู่แล้ว

ในเวอร์ชันก่อนหน้าของ Exchange ถ้าชุดของแฟ้มไม่สมบูรณ์ แต่ไม่ถูกต้องสำหรับ replay ที่เสร็จเรียบร้อยแล้ว กู้คืนนุ่มนวลเริ่ม โดยไม่มีการแจ้งเตือนผู้ดูแลเพิ่มเติม ใน Exchange 2000 และรุ่นใหม่ กว่า ผู้ดูแลระบบต้องเป็นพิเศษแทนข้อผิดพลาด-1216 โดยใช้ Eseutil

เลือกในการคืนค่าเวลาของการสำรองข้อมูลแบบออฟไลน์

การดำเนินการแบบจุดในการคืนค่าเวลาของการสำรองข้อมูลแบบออฟไลน์:
  1. ถ้าฐานข้อมูลที่คุณต้องการคืนค่าอยู่ในปัจจุบัน ถูกเมาท์ dismount ดังกล่าว ถ้าฐานข้อมูลอื่นในกลุ่มการจัดเก็บอยู่ dismounted ของฐานข้อมูลดังกล่าวฐานข้อมูลและการส่งกระแสข้อมูลแฟ้ม (.edb และ.stm) แต่ละต้องสอดคล้องกัน และตรงกัน (เพื่อตรวจสอบความสอดคล้องกันและกัน โปรดดูขั้นตอนที่ 2 ในส่วน "สำรองข้อมูลขึ้นข้อแลกเปลี่ยนฐานข้อมูลออฟไลน์" ของบทความนี้)

    ถ้าฐานข้อมูลในกลุ่มการจัดเก็บข้อมูลทั้งหมดจะ dismounted ฐานข้อมูลทั้งหมดต้องมีความสอดคล้องกัน และยังต้องมีแฟ้มจุดตรวจสอบที่ถูกต้อง แฟ้มจุดตรวจสอบที่ถูกต้องคือ จุดตรวจสอบแฟ้มที่ถูกใช้งานครั้งสุดท้ายที่มีฐานข้อมูลในกลุ่มการจัดเก็บข้อมูลถูกเรียกใช้ ที่มีส่วนหัวที่ E0n.log เป็นจุดตรวจสอบแสดงรายการ ถ้าฐานข้อมูลใด ๆ ในกลุ่มการจัดเก็บข้อมูลยังคงถูกเมาท์ แฟ้มจุดตรวจสอบที่ถูกต้องคือ จุดตรวจสอบแฟ้มที่อยู่ในขณะนี้กำลังถูกใช้ โดยระบบ ถ้าฐานข้อมูลใด ๆ ในกลุ่มการจัดเก็บข้อมูลกำลังทำงาน จุดตรวจสอบที่ถูกต้องแล้ว

    การตรวจสอบแฟ้มจุดตรวจสอบเมื่อฐานข้อมูลทั้งหมดหยุดทำงาน เรียกใช้คำสั่งต่อไปนี้:
    eseutil /mk E0n.chk | /i ค้นหา "จุดตรวจสอบ"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    The following is an example of the output from the preceding commands:
    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)
    							
    In the preceding example, the checkpoint is in the log with the lGeneration of 0x2cc7, which is e00.log. Therefore, the checkpoint can be considered valid.

    If the checkpoint is not valid, you might receive a -1216 error message (JET_errAttachedDatabaseMismatch) when you attempt to mount any database in the storage group. This issue can occur even if all of the databases in the storage group are consistent.
  2. Copy the backed up .edb and .stm files to the appropriate database and streaming file locations. (To find these locations, refer to the "Before You Begin" section of this article.) Verify that the restored files are consistent and matched.

    หมายเหตุ:: If copies of the database files that you want to restore already exist on the server, back these files up before you restore the database, even if the existing files are not startable. They might be repairable, and you might be able to salvage data from them by using the Exmerge utility.
  3. Mount the restored database. The database attaches itself to the end of the E0n.log file. After the database has been successfully started, no previously existing log files can ever be replayed into the database. Public folder databases that contain thousands of folders in the hierarchy may take a long time to start. Allow for at least one minute for every 1,000 folders in the hierarchy.

    In earlier versions of Exchange Server, you usually needed to run theISINTEG -patchcommand after you restored an offline backup of an information store database, to synchronize the information store database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log.
    ชนิดเหตุการณ์: ข้อผิดพลาด
    Event Source: MSExchangeIS Mailbox Store
    Event Category: General
    Event ID: 1087
    Date: 5/4/2001
    Time: 8:33:42 PM
    ผู้ใช้: n/a
    Computer: EXCHANGE1
    Description: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    To resolve this problem, you must click to select theThis database can be overwritten by a restorecheck box in Exchange System Manager, in the Database properties of the database object.

Roll Forward Restoration of an Offline Backup

For the best chance of complete success replaying log files into a restored database:
  • Preserve a copy of all of the transaction logs that were created after the time of your oldest full backup.
  • Do not change a database path without making a new full backup immediately afterward.
  • Do not runESEUTIL /pหรือESEUTIL /dwithout taking a new full backup immediately afterward.
  • Do not add or remove a database in a storage group without immediately making a full backup of all of the databases in the storage group.
To begin the restoration process:
  1. If the database that you want to restore is mounted, dismount it, and then copy the database files that you want to restore to the appropriate paths on the server. If copies of the database files that you want to restore already exist on the server, back these copies up before you restore the database, even if the existing files are not startable. The files may be repairable, and you may be able to use the Exmerge utility to salvage data from them.
  2. Dismount all of the databases in the storage group, and then run the following command against each database in the current storage group, and against each restored database file:
    eseutil /mhdatabase_file_name| find /i "consistent"
    หมายเหตุ:: Exchange 2000 Service Pack 2 and later do not report the database state as "Consistent" or "Inconsistent" but as "Clean Shutdown" or "Dirty Shutdown." ความหมายของ "ใหม่ทั้งหมดปิดระบบ" จะเหมือนกับ "Consistent" และความหมายของ "สกปรกปิดเครื่อง" จะเหมือนกับ "Inconsistent" สำหรับ Exchange 2000 Service Pack 2 หรือในภาย หลัง เรียกใช้คำสั่งนี้เพิ่มเติมเพื่อตรวจสอบสถานะของแต่ละฐานข้อมูล:
    eseutil /mh database_name | ค้นหา /i "ปิดเครื่อง"
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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
    							
    This command has three purposes:
    • To verify that the database files are each consistent.
    • To verify that the .edb and .stm files for each database are a matched pair.
    • To identify the low and high anchor log files, which are the first and last log files that are required to successfully recover all data without generating a -1216 error. The lowest last consistent value across all databases is the low anchor log and the highest last consistent value is the high anchor log.
    ในตัวอย่างก่อนหน้านี้ แฟ้มบันทึกของจุดยึดต่ำ E0002ac8.log และแฟ้มล็อกจุดยึดสูงเป็น E0002cc7.log
  3. ตรวจสอบว่า ลายเซ็นของแฟ้มบันทึกที่บันทึกไว้ในส่วนหัวของแต่ละฐานข้อมูลเป็นลายเซ็นของล็อกจุดยึดต่ำ เรียกใช้คำสั่งต่อไปนี้:
    eseutil /mhdatabase_name| ค้นหา /i "ลายเซ็นของแฟ้มบันทึก"
    eseutil /mllow_anchor_log| ค้นหา /i "ลายเซ็น"
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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:
    							
    ไฟล์บันทึกอาจรายงานลายเซ็นหลาย ลายเซ็นแรกเป็นลายเซ็นของแฟ้มเองล็อกเสมอ ส่วนเหลือเป็นฐานข้อมูลที่ถูกเรียกใช้อยู่ในขณะที่สร้างแฟ้มบันทึก ในตัวอย่างก่อนหน้านี้ ลายเซ็นของแฟ้มบันทึกที่ถูกบันทึกในแฟ้มฐานข้อมูลตรงลายเซ็นของแฟ้มบันทึกในแฟ้มบันทึกของจุดยึดต่ำ

    หากคุณไม่สามารถค้นหาล็อกจุดยึดต่ำ คุณไม่สามารถเล่นแฟ้มบันทึกไปข้างหน้าลงในฐานข้อมูลนั้น ถ้าคุณไม่พบแฟ้มล็อกจุดยึดต่ำ คุณไม่สามารถ replay แฟ้มใด ๆ ที่บันทึกไว้ในฐานข้อมูลใด ๆ มีสองวิธีที่คุณสามารถใช้เพื่อจัดการกับการล็อกจุดยึดที่ต่ำที่ขาดหายไป:
    • คุณสามารถลบแฟ้มบันทึกทั้งหมด เนื่องจากฐานข้อมูลสอดคล้องกันทั้งหมด เริ่มโดยไม่มีอยู่ของแฟ้มบันทึก แต่คุณสูญเสียมีโอกาสในการกู้คืนข้อมูลที่ไม่อยู่ในแฟ้มฐานข้อมูล
    • คุณสามารถลบฐานข้อมูล ด้วยต่ำสุดท้ายสอดคล้องกันค่า จนกว่าคุณสามารถสร้างชุดล็อก unbroken จากน้อยไปสมอสูง และจากนั้น เรียกใช้การกู้คืนข้อมูลในฐานข้อมูลที่เหลือ เมื่อคุณย้ายฐานข้อมูลที่ถูกเอาออกกลับเข้าไปในกลุ่มการจัดเก็บ คุณไม่สามารถ replay ข้อมูลเพิ่มเติมลงในแฟ้มเหล่านั้น
  4. ตรวจสอบว่า เส้นทางที่ตำแหน่งปัจจุบันของฐานข้อมูลเดียวกัน ตามที่พวกเขาได้ในขณะที่คุณทำการสำรองข้อมูล

    แม้ว่าคุณสามารถเปลี่ยนเส้นทางการล็อกธุรกรรมหรือเส้นทางการทำงานหลังจากที่คุณทำการสำรองข้อมูล คุณสามารถเพียงทำ replay ในแฟ้มบันทึกถ้าแฟ้มฐานข้อมูลที่อยู่ในตำแหน่งเดียวกันที่จะถูกสำรองไว้จาก If you are unsure of the original locations, run the following command:
    eseutil /ml"Last_Consistent"_log| find /i "database name or pattern"
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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
    							
    หมายเหตุ:: If the low anchor log is E0n00001.log, it will not have path information in its header, because the header for the first log in a series is generated before the first database is ever attached to the log. In this case, you must look in the next log's header to view database path information. In rare cases, this may also be true for logs later than the first one, because a database was created or attached to the log stream after the log was created.
  5. Gather all of the logs, from the low anchor number as far forward as possible in unbroken sequence, and copy these logs to the current transaction logs path. Do not overwrite logs that are already in place on the server without backing those logs up first. To do this, you may need to restore log files from more than one type of backup media.

    In the preceding example, the low anchor is E0002ac8.log and the high anchor is E0002cc7.log. When you examine available logs, the highest numbered log that you can find might be one number less than the necessary number (for example, E0002cc6.log, instead of 2cc7). This usually occurs because the E0n.log has not yet been filled and renamed to its number in the sequence. To determine whether E0n.log is actually the high anchor log, you must use the following command to examine thelGenerationvalue in the log file header:
    eseutil /ml E0n.log | find /i "lGeneration"
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    หมายเหตุ:: To view the header of a log file with the Eseutil utility, use the/mlswitch; to view a database file header, use the/mhสลับไป If you confuse the switches, the output from the commands is incorrect.

    Typically, the high anchor log is also the highest log available, but this is not true if:
    • Log files have been destroyed in a disaster.

      หรือ
    • You are restoring all of the databases at once in a storage group.
    In the first case, you are likely to encounter -1216 errors during recovery; in the second case, you can play log files forward, even past the high anchor log, as long as they continue the lGeneration sequence.
  6. Verify that all of the logs share the same log signature and are in unbroken sequence. Run the following command:
    eseutil /ml E0n > filename.txt
    ต่อไปนี้คือ ตัวอย่างของผลลัพธ์จากคำสั่งก่อนหน้านี้:
    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.
    							
    This Eseutil command does three things: checks each log file for damage, reports any gap in the log file sequence, and detects log signature mismatches.

    All log signatures must match between all log files that are replay candidates. You must remove any logs that do not have matching signatures before replay begins.

    At this point, after you remove the files that did not pass the verification tests, the only transaction log files in the Transaction Logs folder are files that:
    • Are in unbroken lGeneration sequence, starting with the low anchor log file and continuing up to at least the high anchor log file, and beyond that, if possible.
    • Have matching log signatures.
  7. If the high anchor log is not already named E0n.log, rename it.
  8. Remove the E0n.chk file from the System Path folder.

    In the absence of a checkpoint file, Exchange Server begins to replay the logs from the lowest numbered log file that is available in the Transaction Logs folder: the low anchor log. If the E0n.chk file exists, Exchange Server begins replay at the checkpoint that is recorded in this file. If E0n.chk points past the low anchor log, replay fails entirely for the restored file set. In many cases, if you make a mistake with the checkpoint file, you must start over restoring database files from backup.
  9. As a final check before you mount the storage group, verify that:
    • All of the database files are present in their running paths.
    • The only log files in the running transaction log path are files that start from the low anchor log and continue at least to the high anchor log, with the highest available log named E0n.log.
    • There is no E0n.chk file in the System Path folder.
    You should now be able to successfully mount the storage group and begin to replay transaction logs with this file set. Even after recovery finishes and the database starts, all of the data in all of the log files might not actually be recovered because of DB signature and path issues that are encountered during replay. The "Dealing with Database Signature and Path Mismatches" section of this article provides additional information about these issues.
  10. If the information store is not already running, start it, and then mount at least one database in the storage group. This causes soft recovery to run against all of the databases in the storage group.

    In earlier versions of Exchange Server, you usually need to run theISINTEG -patchcommand after you restore an offline backup of an information store database, to synchronize the database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log.
    ชนิดเหตุการณ์: ข้อผิดพลาด
    Event Source: MSExchangeIS Mailbox Store
    Event Category: General
    Event ID: 1087
    Date: 5/4/2001
    Time: 8:33:42 PM
    ผู้ใช้: n/a
    Computer: EXCHANGE1
    Description: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    To resolve this issue, you must click to select theThis database can be overwritten by a restorecheck box in Exchange System Manager, in the Database properties of the database object.
Check the Application event log in the Microsoft Windows NT Event Viewer for any errors or anomalies that might occur when the database starts. An event 301 is displayed for each log file that is replayed. Watch carefully for errors and warnings during the recovery process.

Dealing with Database Signature and Path Mismatches

Databases, like log files, have their own signatures. But although log signatures do not change after the time that the E0n000001.log file is created, database signatures change whenever the physical topology of the database is altered, without the changes being tracked through the log files. Offline defragmentation or repair of a database with Eseutil changes the DB signature. After such an event, the database can be attached to the same log stream as before, but the database does not accept replay of any transactions that were performed while the database had its earlier signature. An earlier copy of the database does not accept replay of any transaction that was performed after the database's signature changed.

แนะเนื่องจากมีการตั้งค่าลายเซ็นของฐานข้อมูลในลักษณะนี้ คุณจะนำการทำสำรองฐานข้อมูลทั้งหมดทันทีหลังจากการจัดเรียงข้อมูลแบบออฟไลน์หรือซ่อมแซมฐานข้อมูล ถ้าคุณคืนค่าสำเนาของฐานข้อมูลที่มีลายเซ็นเก่าในภายหลัง replay สำเร็จจนถึงจุดเปลี่ยนลายเซ็น แต่คุณสูญเสียการเปลี่ยนแปลงทั้งหมดที่จุดที่ผ่านมา

ถ้ามีเปลี่ยนเส้นทางฐานข้อมูลในตรงกลางของกระแสข้อมูลล็อก ผลจะเหมือนกับของการเปลี่ยนลายเซ็น: replay ถูกขัดจังหวะใน point ของการเปลี่ยนแปลง (API การสำรองข้อมูลแบบออนไลน์แสดงสิ่งอำนวยความสะดวกการ remap เส้นทางในระหว่างการกู้คืน ดังนั้น API การสำรองข้อมูลแบบออนไลน์สามารถ replay ล็อกทั้งหมด ถึงแม้ว่าเส้นทางที่มีการเปลี่ยนแปลงตั้งแต่มีดำเนินการสำรองข้อมูล)

เป็นลายเซ็นของฐานข้อมูลหรือฐานข้อมูล การตัดสินค้าจากคลังของเส้นทางที่พบระหว่างการ replay เหล่านั้นลายเซ็นของฐานข้อมูล หรือเส้นทางฐานข้อมูลมีรายงานปัญหาในการบันทึกเหตุการณ์ของโปรแกรมประยุกต์ line with เหตุการณ์ 301 replay สำหรับแต่ละแฟ้มล็อก แฟ้มบันทึกที่มีจุดของปัญหาที่ผ่านมาอาจปรากฏขึ้นเพื่อที่ เล่นเสร็จเรียบร้อยแล้ว แต่เป็นเท่านั้นเนื่องจากคำเตือนไม่ตรงกันจะไม่ซ้ำล็อก ตามกฎทั่วไป replay ลงในฐานข้อมูลที่เฉพาะถูกตัดทอนจากจุดที่เกิดข้อผิดแรกฐานข้อมูลลายเซ็นหรือเส้นทางพลาดอ้างอิงถึงฐานข้อมูลนั้น

คุณสมบัติ

หมายเลขบทความ (Article ID): 296788 - รีวิวครั้งสุดท้าย: 8 มกราคม 2554 - Revision: 3.0
ใช้กับ
  • 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
Keywords: 
kbproductlink kberrmsg kbhowto kbmt KB296788 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:296788

ให้ข้อเสนอแนะ

 

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