原文作者：克雷格·穆利斯
原文地址：https://www.dbta.com/Columns/DBA-Corner/Why-You-Must-Integrate-Database-Archiving-and-Recovery-153239.aspx
数据归档是数据治理和数据管理的一个重要方面。归档不仅有助于降低硬件和存储成本，而且还是长期数据保留的一个重要方面，也是监管合规工作的关键参与者。
当您的数据需要长期保留数据（超过几年）时，将其归档可能是最佳解决方案。首先，归档数据可以提高运营平台的效率，因为需要处理和管理的数据更少。其次，必须长期存储的大量数据可能会挑战您的运营平台的极限。最后，存档旨在控制数据的真实性以及在数据保留期过后删除数据。
确保正确的数据恢复
好的，所以如果我们将数据归档到单独的归档数据存储中，我们需要将归档策略与备份计划集成。这是强制性的，以确保可以正确有效地执行根据定义未计划的数据恢复。
数据归档是在预计不会再次引用该数据时从您的操作系统中删除选定数据记录的过程。此外，数据存储在存档数据存储中，可以根据需要进行检索。非常重要的是要记住，当数据从操作平台存档时，无论是数据库系统、电子邮件平台还是任何其他数据存储机制，该数据不再存储在其操作源中，而仅存储在档案。
到目前为止，一切都很好。但现在让我们考虑一些潜在的恢复方案。假设在每周的批处理周期中，运行的作业错误地修改了操作数据库中的数据。此外，同一天，还运行了一项数据库归档策略，该策略导致数据从操作数据库中删除。如果我们不小心，我们的恢复不仅会逆转错误所做的更改，还会逆转被删除并移动到存档数据存储的数据。在这种情况下，数据将同时存在于操作数据库和存档数据存储中。下次我们为该数据库执行归档策略时，我们将再次归档数据，这将导致归档中的数据重复。
为了避免这种情况，DBA 必须知道何时运行数据库归档策略。DBA 需要确保恢复不会应用从存档中删除的数据，或者在恢复后立即丢弃存档数据存储中的数据。前一种解决方案可能比后者更好。
不同的组织需要不同的方法
当然，很大程度上取决于数据库恢复的复杂性。考虑以下情况：进程 1 运行并进行错误更改，存档策略运行，然后进程 2 运行，也进行了错误更改。如果您将数据库恢复到过程 1 之前的时间点，您将在恢复中包含存档数据。如果您有一个基于日志的恢复方案，可以通过扭转进程的影响来应用应用程序恢复，那么您可以为两个进程运行它并避免重新应用归档数据。
DBA 可能面临无数的恢复场景，因此在涉及归档时提出数据库备份和恢复的分步指南是不切实际的（如果不是不可能的话）。可以这么说，您需要将用于恢复数据库的知识和策略与您的数据库存档相结合。
此外，尽管给出的示例侧重于数据库系统，但在任何其他操作平台上都可能出现相同类型的问题，在这些平台上，数据既存档又备份以用于可能的恢复场景。
