Резервне копіювання журналу Tail Log при виконанні відновлення?

Зазвичай під час відновлення БД з виробничого сервера на невиробничий сервер я буду використовувати параметр "ЗАМЕНИТИ", оскільки коли я забуду, я отримав помилку щодо не резервного копіювання журналу хвоста.

Згідно з MSDN, я дійсно повинен створювати резервну копію журналу хвоста перед відновленням:

Якщо база даних є в Інтернеті, і ви плануєте виконати операцію відновлення бази даних, почніть із резервного копіювання хвоста журналу. Щоб уникнути помилки в Інтернет-базі даних, ви повинні використовувати параметр… З NORECOVERY оператора BACKUP Transact-SQL.

Які існують небезпеки чи недоліки того, як я це роблю? Чому резервне копіювання хвостового журналу є першою перевагою для мене?

Я використовую SQL Server 2008R2, але я припускаю, що цей запит буде стосуватися більшості новіших версій SQL Server, тому спочатку не позначав його як такий.

sql-server restore transaction-log

— Пол
джерело

Я думаю, це означає, що якщо ви збираєтесь відновити в одному місці (і потенційно застосувати додаткові журнали транзакцій). Якщо ви збираєтеся відновлювати лише просту копію бази даних в іншому місці, і вам не потрібно підтримувати ланцюжок журналів, я б використовував метод, який ви використовуєте. Можливо, я б навіть використовував WITH COPY_ONLYрезервну копію.

— Аарон Бертран

Якщо ви не створили резервну копію хвоста журналу, ви втратите будь-які транзакції, що відбулися з моменту останньої резервної копії бази даних.

— ЖозеТейшейра
джерело

Так, я це зрозумів. Але навіть я вважаю, що ваша відповідь змусила мене подолати розрив у моєму мисленні. Дивіться, що невиробничий БД ніколи не створюється резервна копія, тому я втрачаю всю БД, відновивши все одно, чому б я піклувався про журнал хвоста. Але думка MSDN полягає в тому, що я завжди створюю резервну копію своєї БД, єдиний біт, який зараз не створюється резервна копія, - це хвостовий журнал, тому вони хочуть, щоб я його створив. Для мого конкретного сценарію тимчасової невиробничої БД, про яку ніхто не піклується, тому немає переваги резервного копіювання журналу хвоста.

— Павло

Цілком правильно. Якщо ви просто хочете донести дані до невиробничого середовища і не дуже цікавитесь тим, що там було, то насправді взагалі немає жодної проблеми.

— JoseTeixeira