การสำรองข้อมูล exchange Server 2003 และบริการต่าง ๆ ของ Volume Shadow Copy

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

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

สรุป

คุณลักษณะการบริการ Volume Shadow Copy ใน Microsoft Windows Server 2003 สามารถใช้ในการสร้างแอปพลิเคชันที่สำรองข้อมูล และการคืนค่า Microsoft Exchange Server 2003 Windows Volume Shadow คัดลอก Service (VSS) แสดงโครงสร้างพื้นฐานที่ช่วยให้โปรแกรมจัดการการเก็บข้อมูลอื่น โปรแกรมธุรกิจ และผู้ให้บริการของฮาร์ดแวร์เพื่อ cooperate ในการสร้าง และจัดการสำเนาเงา วิธีการแก้ไขปัญหาที่ขึ้นอยู่กับโครงสร้างพื้นฐานนี้สามารถใช้สำเนาเงา (หรือคัดลอกที่มิเรอร์) การทำสำรอง และคืนค่าฐานข้อมูล Exchange Server 2003 อย่าง น้อยหนึ่ง

สื่อสารพิกัดบริการ Volume Shadow Copy ระหว่างrequestorsโปรแกรม (สำรองประยุกต์),ผู้เขียน("โปรแกรมประยุกต์ในบริการของ Windows เช่นเดียวกับ Exchange Server 2003 และ SQL Server 2000), และผู้ให้บริการ(ระบบ ซอฟต์แวร์ หรือฮาร์ดแวร์ไปป์ที่สร้างสำเนาเงา) เมื่อต้องการใช้คุณลักษณะการบริการ Volume Shadow Copy เพื่อสำรองข้อมูล Exchange Server 2003 โปรแกรมสำรองข้อมูลต้องรวมข้อ Exchange Server 2003 ทราบ Volume Shadow Copy บริการ requestor เนื่องจากโปรแกรมสำรองข้อมูลที่รวมกับเซิร์ฟเวอร์ Windows มี requestor เช่นไม่มี องค์กรต้องใช้โปรแกรมประยุกต์การสำรองข้อมูลของบริษัทอื่น

เพื่อให้สามารถเข้ากันได้กับ Exchange Server 2003, VSS ที่ใช้ในการสำรองข้อมูลโปรแกรมประยุกต์ต้องตามข้อกำหนดพื้นฐานสามเพื่อตรวจสอบความถูกต้องและ recoverability ของสำเนาสำรองของสำเนาเงา ถ้าข้อกำหนดเหล่านี้ไม่มีตาม บริการสนับสนุนผลิตภัณฑ์ของ Microsoft (PSS) จะพิจารณาว่าโซลูชันการสำรองข้อมูลจะอยู่ภายนอกของกรอบการทำงานของ Exchange VSS และจะไม่สามารถแก้ไขปัญหาการทำสำรอง และการคืนค่าการตัดสินค้าจากคลัง ลูกค้าควรตรวจสอบกับผู้ขายที่มีการสำรองข้อมูลของตนเองว่า โปรแกรมประยุกต์ที่มีการสำรองข้อมูลที่ตอบสนองความต้องการแลกเปลี่ยนไปตามที่แสดงในบทความฐานความรู้นี้ รายละเอียดของข้อกำหนดของ Exchange VSS ถูกแสดงในส่วน "ข้อมูลเพิ่มเติม" ของบทความนี้

ตาม ด้วยโซลูชันใด ๆ ของบริษัทอื่น ผู้ขายของแอพลิเคชันที่สำรองข้อมูลเป็นผู้ให้บริการสนับสนุนหลักสำหรับปัญหาการทำสำรองและการกู้คืน pss สามารถช่วยคุณในการวิเคราะห์ หรือวิเคราะห์ปัญหาเกี่ยวกับฐานข้อมูลที่พร้อมใช้งานและการตั้งค่าแฟ้มล็อกธุรกรรม อย่างไรก็ตาม Microsoft ไม่ได้แก้ไข หรือการตรวจแก้จุดบกพร่องผลิตภัณฑ์ของบริษัทอื่น การขอความช่วยเหลือของ pss ถูกจำกัดให้คำแนะนำเกี่ยวกับวิธีการที่ดีที่สุดต่อการกู้คืนฐานข้อมูลที่พร้อมใช้งานและแฟ้มล็อกธุรกรรม

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีสนับสนุน VSS ที่ขึ้นอยู่กับวิธีการแก้ไขปัญหาโดย PSS คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
841696ภาพรวมของวิธีแก้ไขปัญหาซอฟต์แวร์การเก็บข้อมูลของบริษัทอื่น Microsoft สนับสนุนนโยบาย

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

รายการต่อไปนี้อธิบายการสำรองข้อมูล Exchange Server 2003 กับกระบวนการบริการของ Volume Shadow Copy:

  1. การสำรองข้อมูลโปรแกรม (หรือผู้ทำหน้าที่) รันงานที่กำหนดเวลาไว้
  2. บริการ Volume Shadow Copy Requestor ในโปรแกรมสำรองส่งคำสั่งไปยังบริการ Volume Shadow Copy ใช้ shadow copy ของกลุ่มการจัดเก็บข้อมูล Exchange Server 2003 ที่เลือก
  3. บริการ Shadow Copy ของไดรฟ์ข้อมูลที่สื่อสารกับ Writer Exchange Server 2003 เพื่อเตรียมสำหรับการสำรองข้อมูล snapshot
  4. บริการ Shadow Copy ของไดรฟ์ข้อมูลที่สื่อสารกับผู้ให้บริการที่เก็บที่เหมาะสมเพื่อสร้าง shadow copy ของไดรฟ์ข้อมูลเก็บข้อมูลหรือไดรฟ์ข้อมูลเก็บข้อมูลที่ประกอบด้วยกลุ่มการจัดเก็บข้อมูล Exchange Server 2003 หรือกลุ่มการจัดเก็บ
  5. บริการ Shadow Copy ของไดรฟ์ข้อมูลออก Exchange Server 2003 กลับมาทำงานของการดำเนินการปกติ
  6. บริการ Volume Shadow Copy Requestor ตรวจสอบความสมบูรณ์ของชุดการสำรองข้อมูลก่อนที่จะแจ้ง Exchange ให้ สำรองข้อมูลเสร็จสมบูรณ์
ตัวอย่างเช่น เมื่อการร้องขอการสำเนาเงาได้รับจากโปรแกรมสำรองข้อมูล Exchange Server 2003 ที่มีบริการ Volume Shadow Copy ที่สนับสนุนการ (แบบ requestor), Volume Shadow Copy บริการสื่อสารกับ Writer Exchange Server 2003 เพื่อเตรียม snapshot ณจุดนี้ Exchange Server 2003 prohibits การดำเนินการในการจัดการกับกลุ่มการจัดเก็บ การตรวจสอบการอ้างอิงของระดับเสียง และ suspends ทั้งหมดเขียนการดำเนินการกับฐานข้อมูลและแฟ้มล็อกธุรกรรมในขณะที่อนุญาตให้เข้าถึงแบบอ่านอย่างเดียว Volume Shadow Copy service then communicates with the appropriate storage provider to initiate the shadow copy process for the disk volumes that contain the Exchange Server 2003 data. The shadow copy typically takes couple of seconds which will be practically imperceptible to the end user. When the shadow copy has been taken, Volume Shadow Copy service communicates with the Exchange Server 2003 Writer that Exchange can resume ordinary operations. Backup program verifies the health of the shadow copy prior to informing Exchange that the backup was successful. At the end of a successful backup Exchange truncates the logs and records the time of the last backup for the database or databases.

For more information about Exchange Server 2003 backup with Volume Shadow Copy services, click the following article number to view the article in the Microsoft Knowledge Base:
842066TechNet Support WebCast: Volume Shadow Copy for Exchange Server 2003

The following list describes the Exchange Server 2003 requirements that any shadow copy backup applications must follow to ensure the integrity and recoverability of Exchange databases:

The list below provides the specific Application event logs that identify if the Exchange requirements are being followed. Backup applications and the Exchange server may log other events associated with the backup and restore process. Confirming that the following events are logged during backup and restore will serve as the verification of compliance with Exchange VSS requirements. Currently, there is no certification program for any third party software solution running on Exchange. Compliance ensures the integrity and recoverability of shadow copy backups but makes no warranty on the performance or reliability of the third party solution.
  1. Exchange database, transaction log and checkpoint files must be backed up exclusively through the Exchange Writer:

    The following application events will be logged if the Exchange Writer is initiated during shadow copy backups.

    Event Type: Information
    Event Source: ESE
    Event Category: ShadowCopy
    Event ID: 2005
    Date: 6/17/2004
    Time: 11:40:41 AM
    User: N/A
    Computer: EXCHSERVER
    Description: Information Store (2180) Shadow copy instance 3 starting. This will be a “Backup Type”* shadow copy.

    * Where “Backup Type” is the type of backup performed (Full, Copy, Incremental or Differential).

    Event Type: Information
    Event Source: MSExchangeIS
    Event Category: Exchange VSS Writer
    Event ID: 9608
    Date: 6/17/2004
    Time: 11:40:42 AM
    User: N/A
    Computer: EXCHSERVER
    Description: Exchange VSS Snapshot prepared for Snapshot successfully.

    Event Type: Information
    Event Source: MSExchangeIS
    Event Category: Exchange VSS Writer
    Event ID: 9610
    Date: 6/17/2004
    Time: 11:40:43 AM
    User: N/A
    Computer: EXCHSERVER
    Description: Exchange VSS Snapshot has frozen the storage groups successfully.

    Event Type: Information
    Event Source: MSExchangeIS
    Event Category: Exchange VSS Writer
    Event ID: 9612
    Date: 6/17/2004
    Time: 11:40:44 AM
    User: N/A
    Computer: EXCHSERVER
    Description: Exchange VSS Snapshot has thawed the storage groups successfully.

  2. The backup application must validate the integrity of the shadow copy backup set.

    Microsoft recommends, but does not require, that this be done before the backup application notifies Exchange that backup has completed. The reason for this recommendation is that Exchange performs two important tasks after a successful backup:
    • Exchange updates the headers of the backed up databases to reflect the last successful backup time
    • Exchange removes (“prunes”) transaction logs from the server that are no longer required to roll forward from the last successful backup.
    If a backup application postpones integrity verification until after these tasks have completed, then special care must be taken to preserve the last verified backup along with copies of all log files required by that backup. Although the backup may have already been reported as successful to Exchange, the backup should not be relied on until the backup application has actually completed integrity verification.

    โปรดดูรักษาไป "วิธีการทำตามการตรวจสอบความสมบูรณ์ของการสำรองข้อมูล VSS" ส่วนของบทความนี้สำหรับรายละเอียดที่สมบูรณ์เกี่ยวกับวิธีการดำเนินการการตรวจสอบความถูกต้อง และวิธีการตรวจสอบที่ฐานข้อมูล และแฟ้มล็อกธุรกรรมต้องเป็นไว้จนกว่าจะเสร็จสิ้นการตรวจสอบความถูกต้อง
  3. คืนไปยังตำแหน่งที่ตั้งเดิม ** เป็นต้องกระทำแบบเอกสิทธิ์เฉพาะบุคคลกับโปรแกรมจัดการข้อความการแลกเปลี่ยน

    ตัวเขียน exchange จะเข้าสู่ระบบต่อไปนี้ของเหตุการณ์ในล็อกเหตุการณ์ของแอพลิเคชันในระหว่างกระบวนการคืนค่าสำเนาเงา

    ชนิดเหตุการณ์: ข้อมูล
    แหล่งที่มาของเหตุการณ์: MSExchangeIS
    ประเภทของเหตุการณ์: ตัวเขียน VSS การแลกเปลี่ยน
    รหัสเหตุการณ์: 9620
    วัน: 6/17/2004
    เวลา: 1:49:59 PM
    ผู้ใช้: n/a
    คอมพิวเตอร์: EXCHSERVER
    คำอธิบาย: Exchange VSS Snapshot ได้ประมวลผล pre-restore เหตุการณ์เสร็จเรียบร้อยแล้ว

    ชนิดเหตุการณ์: ข้อมูล
    แหล่งที่มาของเหตุการณ์: MSExchangeIS
    ประเภทของเหตุการณ์: ตัวเขียน VSS การแลกเปลี่ยน
    รหัสเหตุการณ์: 9618
    วัน: 6/17/2004
    เวลา: 1:59:46 PM
    ผู้ใช้: n/a
    คอมพิวเตอร์: EXCHSERVER
    คำอธิบาย: Exchange VSS Snapshot ได้ประมวลผล post-restore เหตุการณ์เสร็จเรียบร้อยแล้ว

** "ตำแหน่งเริ่มต้น" หมายความว่า คอมพิวเตอร์ Exchange ที่ มีชื่อเดียวกันของเซิร์ฟเวอร์และเส้นทางแฟ้มเดียวกันกับคอมพิวเตอร์ Exchange ที่มีดำเนินการสำรองข้อมูล VSS

ไม่สามารถเป็นได้คืนไปยังตำแหน่งที่ตั้งอื่นโดยใช้โปรแกรมการจัดการข้อความของ Exchange ที่เป็นของ Exchange Server 2003 SP1 โปรแกรมประยุกต์การสำรองข้อมูล vss ใช้สามารถเลือกที่จะใส่ด้วยตนเองหรือวิธีการอื่น ๆ โดยทางโปรแกรมจะคืนค่าสำเนาสำรองของฐานข้อมูล Exchange ไปยังตำแหน่งที่ตั้งอื่น

วิธีการดำเนินการตรวจสอบความถูกต้องสำหรับการสำรองข้อมูล VSS

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

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

ถ้าคุณไม่ checksum-ตรวจของการสำรองข้อมูล VSS เป็นไปได้ว่า เพจที่เสียหายอาจยังคงตรวจไม่พบในฐานข้อมูล และกระทั่งกลายเป็นในการสำรองข้อมูลที่มีอยู่ทั้งหมด วิธีเดียวที่สามารถกู้คืนจาก circumstance นี้คือการ ซ่อมแซมฐานข้อมูล ซ่อมแซมฐานข้อมูลต้องใช้ downtime รุนแรง และจะทำให้ข้อมูลสูญหายอย่างน้อยบางอย่าง (น้อยสูญหายของข้อมูลที่อยู่บนเพจที่เสียหาย)

อย่างไรก็ตาม ถ้ามีการตรวจสอบการสำรองข้อมูล VSS ล่าสุดของคุณมีเพจทั้งหมดที่ดี คุณสามารถกำจัดเพจที่เสียหายจากฐานข้อมูล โดยการคืนค่าการตรวจสอบการสำรองข้อมูล และนำไปข้างหน้านั้น ด้วยล็อกธุรกรรมที่สร้างขึ้นเนื่องจากดำเนินการสำรองข้อมูล downtime จำเป็นต้องทำเช่นนี้มักจะมากสั้นกว่าสำหรับการซ่อมแซมฐานข้อมูล และวิธีการกู้คืนนี้สามารถแก้ไขปัญหาของฐานข้อมูลเกี่ยวกับการสูญเสียข้อมูลเป็นศูนย์

ซึ่ง คุณไม่ควรสำรองข้อมูล VSS จะดีจนกว่าแฟ้มทั้งหมดที่อยู่ในนั้นได้รับการตรวจสอบ checksum

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

สิ่งสำคัญข้อกำหนดนี้ใช้การสำรองผ่านการตรวจสอบความสมบูรณ์ของข้อมูลล่าสุด ไม่ให้การสำรองข้อมูลทำล่าสุด จนกว่าการสำรองข้อมูลล่าสุดได้ผ่านการตรวจสอบ checksum มันจะไม่พิจารณาการสำรองข้อมูลที่ถูกต้อง

อีกวิธีหนึ่งคือ คุณอาจยังรักษาแฟ้มบันทึกเพิ่มเติมที่จำเป็นต้องอย่างสมบูรณ์หมุนฐานข้อมูลไปข้างหน้าหลังจากการคืนค่าของสำเนาสำรองฐานข้อมูล These are all the transaction logs in unbroken sequence starting with the lowest Log Required file up to the most recently created transaction log that has been purged from the Exchange server. Detailed examples and explanations of what this means are provided below.

Preserving transaction logs beyond those listed in the Log Required range(s) is optional, in the sense that doing so is not strictly required in order to successfully restore and mount a backed up database. However, if you do not preserve all these logs, then restoring from backup will cause you to lose all changes in the database past the point of backup. Microsoft strongly recommends that you not only preserve the transaction logs required to restore and mount a backed up database, but also all subsequent transaction logs needed to roll the database forward without data loss.

Determining which transaction log files are required

If an Exchange database is backed up while it is online, at least one transaction log file will always be backed up with it. This is regardless of whether you use the streaming backup API or the VSS backup API.

After restoration of an online backup, information from the transaction logs must be applied to the database ("replayed") before the database will be mountable again. The Log Required field of each database header records the sequence (generation) numbers of the range of transaction log files that must be replayed into the database.

If the Log Required field reads 0-0, this means that the database is mountable without having to replay any additional transaction log data. The only time the Log Required value will be 0-0 is after a database is brought into a clean-shutdown state. While a database is running, the Log Required field always records the range of transaction logs that have not yet been applied to the database. This range is updated continually.

A database backed up online will always have a non-zero Log Required range, and these logs must be backed up along with the database. If, after restoration, these logs are not available, the database will not be mountable. (You can repair the database if the necessary logs cannot be found, but there is no guarantee that repair will be successful, and repair will almost always result in some level of data loss, even if only the data in the missing logs.)

If you use the Exchange streaming backup API or the VSS backup API contained in the Exchange VSS writer, then required log files needed to mount a database will be backed up automatically with the database. If you replay only the Log Required files, this will result in the database being restored to the point in time at which the backup finished. If you wish to roll the database forward past that point, you must also play the log files generated after the backup was done.

In order to completely roll the database forward from any particular backup, you must preserve all the log files in unbroken sequence starting from the lowest log in the Log Required range up to the most recently generated log file in the database's storage group. If any log in this series is missing or damaged, you will only be able to roll forward up to the point of the last good log before the missing or damaged file.

Therefore, if you wish to recover from backup with no data loss, it is essential that you maintain good copies of all transaction log files going forward from your last verified good database backup.

Transaction log pruning

If transaction logs are not removed from an Exchange server, they will continue to accumulate until they fill all available disk space. Therefore, both the streaming and VSS backup APIs support "pruning" of transaction log files after completion of a Normal or Incremental backup. Log files older than those needed to recover the most recent backup are automatically deleted from the server after the backup applications signals Exchange that backup has completed successfully.

With the streaming API, checksum verification of the database is done during the backup process. By the time a backup completes, the entire database and the required log files have been checked for physical integrity. With the VSS API, checksum verification cannot be done as part of the actual backup process. The vendor must verify the physical integrity of the database independently of the backup process. This can be done with Eseutil either before or after signaling Exchange that the backup has completed.

If checksum verification is done before backup completes, and a problem is found in the backup set, then Exchange can be informed that the backup was unsuccessful. Doing this will prevent Exchange from pruning log files from the server.

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

Microsoft จึงแนะนำ แต่ไม่จำเป็น ต้อง ให้ตรวจสอบ checksum สามารถทำได้ในการสำรองข้อมูล VSS ก่อนที่โปรแกรมประยุกต์การสำรองข้อมูลสัญญาณความสมบูรณ์ที่สำรองข้อมูลเพื่อแลกเปลี่ยน ถ้ามีการตรวจสอบ checksum ถูกเลื่อนออกไปจนกว่าหลังจากการสำรองข้อมูลเรียบร้อยแล้ว เสร็จสมบูรณ์แล้วโปรแกรมประยุกต์ที่มีการสำรองข้อมูลที่ต้องให้ว่า มีการจัดทำสำเนาของ แฟ้มล็อกธุรกรรมทั้งหมดที่ถูก pruned จากเซิร์ฟเวอร์ ยกเว้นที่นำไปข้างหน้าทั้งหมด ไม่ได้ความสำคัญสำหรับคุณ

ในกรณีส่วนใหญ่ ล็อกธุรกรรมทั้งหมดที่จำเป็นต้องย้อนไปข้างหน้าในการสำรองข้อมูล VSS จะพร้อมใช้งานในชุดของแฟ้มบันทึกที่บันทึกไว้กับการสำรองข้อมูลก่อนหน้านี้พร้อมกับตัวที่บันทึกไว้กับการสำรองข้อมูลปัจจุบัน อย่างไรก็ตาม ลูกค้าควรตรวจสอบว่า เป็นกรณีนี้เมื่อ considering ผู้จัดจำหน่ายเฉพาะ

การคืนค่าสำเนาสำรอง unverified

อาจมีกรณีที่จำเป็นต้องใช้การคืนค่าที่เป็นความเสียหายเกิดก่อน checksum การตรวจสอบเสร็จสมบูรณ์ในการสำรองข้อมูลล่าสุด ในกรณีเช่น Microsoft แนะนำให้ คุณคืนค่าสำเนาสำรองก่อนหน้านี้ที่ตรวจสอบ และหมุนการสำรองข้อมูลนั้นไปข้างหน้า แทน relying บนการสำรองข้อมูล unverified

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

วิธีการตรวจสอบความสอดคล้อง snapshot

Requestor vss ต้องตรวจสอบความสอดคล้อง snapshot โดยการรัน Eseutil.exe กับฐานข้อมูลและการบันทึกแฟ้มโดยใช้ตัวเลือกที่เหมาะสมในตารางต่อไปนี้ Requestor vss ต้องตรวจสอบว่า ทั้งหมดที่ออก ERRORLEVELs ที่มีการส่งคืนจะไม่เป็นลบ เมื่อต้องดู ERRORLEVEL บรรทัดคำสั่งที่ พิมพ์echo % errorlevel %หลังจากที่ Eseutil.exe เสร็จสิ้นการทำงาน ERRORLEVEL ที่เป็นค่าลบหมายความ ว่า มีความเสียหายในแฟ้ม ก่อนที่จะเรียก Requestor VSSBackupComplete, Requestor VSS ต้องแน่ใจว่า สถานะของคอมโพเนนต์สำรองข้อมูลในเอกสารของคอมโพเนนต์ Backup สะท้อนถึงผลลัพธ์ของการตรวจสอบความสอดคล้องกัน นั่นคือ สถานะของคอมโพเนนต์สำรองควร FALSE ถ้ามีความเสียหายอยู่เรียบร้อยแล้ว และควรเป็น TRUE ถ้าพบความเสียหายไม่ ตรวจสอบความสอดคล้อง snapshot คือ ความต้องการบังคับสำหรับการแก้ไขปัญหาจะได้รับการสนับสนุน โดยทีม Exchange

ตารางต่อไปนี้แสดงชุดของการตรวจสอบความถูกต้องสำหรับแต่ละชนิดการสำรองข้อมูล
ยุบตารางนี้ขยายตารางนี้
ชนิดของแฟ้ม \ ชนิดการสำรองข้อมูลการสำรองข้อมูลเต็มรูปแบบการคัดลอกการสำรองข้อมูลการสำรองข้อมูลแบบเพิ่มหน่วยการสำรองข้อมูลส่วนที่แตกต่าง
.edb" eseutil /k /i ”" eseutil /k /i"nana
.log"eseutil /k" *"eseutil /k" *"eseutil /k" **"eseutil /k" **
.stmnananana
.chknananana

เนื่องจากการแนปธรรมชาติของการสำรองข้อมูล VSS, JET ไม่มีโอกาสที่จะสัมผัสเพจทั้งหมดที่ทำในการตรวจสอบความสอดคล้องกันที่จำเป็น ดังนั้น จึงเป็นความรับผิดชอบของ VSS Requestor เพื่อตรวจสอบความสอดคล้อง snapshot

* ล็อกแฟ้มทั้งหมด ด้วยการบันทึกแฟ้มสร้างจำนวนเท่ากับ หรือสูงกว่าจุดตรวจสอบล็อกไฟล์ที่จำเป็นต้องกู้คืนฐานข้อมูลสำเนาชั่วคราว ถ้ามีปัจจุบันที่แฟ้มบันทึก (Enn.log) ยังจำเป็นสำหรับการกู้คืนฐานข้อมูล ให้แน่ใจว่าใด ๆ ของแฟ้มล็อกที่จำเป็นต้องใช้ล้มเหลวการตรวจสอบความสอดคล้อง Requester ต้องว่าว่า สถานะของคอมโพเนนต์การสำรองข้อมูลถูกตั้งค่าการ FALSE ก่อนการโทรศัพท์BackupComplete. การตรวจสอบแฟ้มบันทึกของจุดตรวจสอบ รัน eseutil.exe กับจุดตรวจสอบแฟ้มสำเนาชั่วคราว และการแยกวิเคราะห์ผลลัพธ์สำหรับ "จุดตรวจสอบ: " ตัวอย่างเช่น "c:\eseutil.exe /mk E01.chk" แสดงต่อไปนี้:
Checkpoint:  (0x20,9D,187)
โดยที่ 0x20 คือ หมายเลขการสร้างแฟ้มบันทึกของจุดตรวจสอบล็อกไฟล์

ในตัวอย่างนี้ ใด ๆ ล็อก แฟ้ม รวมทั้ง E0100020.log และข้างต้น ต้องเสียไม่หายการกู้คืนฐานข้อมูล snapshot แม้ว่าฐานข้อมูลเองมีอยู่แล้วผ่านการตรวจสอบความสอดคล้องกันที่มีอยู่จริง

** ทุกแฟ้มบันทึกใน Incremental ข้อ หรือชุดการสำรองข้อมูลส่วนที่แตกต่างจำเป็นสำหรับการกู้คืนฐานข้อมูล Consistency of a whole log sequence can be checked by running eseutil against the log file prefix. For example, “eseutil /k E01” will run consistency checks against all files of the form E01xxxxx.log on a given path.

คุณสมบัติ

หมายเลขบทความ (Article ID): 822896 - รีวิวครั้งสุดท้าย: 14 มกราคม 2554 - Revision: 4.0
ใช้กับ
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition เมื่อใช้กับ:
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003 Datacenter Edition
    • Microsoft Windows Server 2003 Enterprise Edition
    • Microsoft Windows Server 2003 Standard Edition
    • Microsoft Windows Server 2003 Web Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Keywords: 
kbtshoot kbmt KB822896 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:822896

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

 

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