Недавно у нас произошел сбой на одном из наших серверов. Сервер был недоступен, и мы могли получить с него какие-либо данные. У нас был план резервного копирования, в котором полное резервное копирование делалось каждые два дня, а затем резервное копирование различий каждые 6 часов или что-то в этом роде.
Я использую Jungle Disk для переноса данных с сервера на внешнее хранилище, и на этот раз это нам не удалось. Всегда будет задержка между завершением резервного копирования и копированием файла Jungle Disk в облако. И в этом случае наша последняя резервная копия различий была сделана примерно за час до этого, и поэтому все предыдущие резервные копии различий были бесполезны.
Есть ли способ настроить резервную копию diff, чтобы мне не всегда приходилось иметь последнюю версию резервной копии diff и просто восстанавливать резервную копию с таким количеством резервных копий diff, которые у меня есть?
Я знаю, что это старая ветка, но я наткнулся на нее, исследуя другую проблему с JungleDisk.
Проблема с OP заключалась в том, что каждый взятый дифференциал имел то же имя, что и предыдущий, а JungleDisk перезаписывал старую облачную резервную копию новым файлом. Не проблема, если только последнее резервное копирование в облако не завершилось неудачно ... что и случилось в его случае.
Но ответ на вопрос OP: да, в вашем плане обслуживания переименуйте каждую дифференциальную резервную копию с отметкой даты и времени. Например, вот план, который создает такое имя файла, как:
MyDatabaseName_Diff_2012-08-20T01-35-01.BAK
DECLARE @name VARCHAR(50) -- database name
DECLARE @path VARCHAR(256) -- path for backup files
DECLARE @fileName VARCHAR(256) -- filename for backup
DECLARE @fileDate VARCHAR(20) -- used for file name
DECLARE @fileNameNoExt VARCHAR(256) -- Used to name the backup from the NAME parameter
DECLARE @subDir VARCHAR(256) -- Used to create the subdirectory for the backup
DECLARE @backupSetId as int
DECLARE @noBackupErrorMessage VARCHAR(256)
SET @path = 'C:\Path\To\Your\Backups\'
SELECT @fileDate = REPLACE(REPLACE(CONVERT(VARCHAR(20),GETDATE(),126), ':', '-'), '.', '')
-- Exclude the system databases, as well as any others you don't want to back up.
DECLARE db_cursor CURSOR FOR
SELECT name
FROM master.dbo.sysdatabases
WHERE name NOT IN ('master','model','msdb','tempdb')
OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
SET @fileName = @path + @name + '\' + @name + '_Diff_' + @fileDate + '.BAK'
SET @fileNameNoExt = @name + '\' + @name + '_Diff_' + @fileDate
SET @subDir = @path + @name
EXECUTE master.dbo.xp_create_subdir @subdir
BACKUP DATABASE @name TO DISK = @fileName WITH DIFFERENTIAL, NOFORMAT, NOINIT, NAME = @fileNameNoExt, SKIP, NOREWIND, NOUNLOAD, STATS = 10
-- Now verify the backup
SET @noBackupErrorMessage = N'Verify failed. Backup information for database ' + @name + ' not found.'
select @backupSetId = position from msdb..backupset where database_name=@name and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=@name )
if @backupSetId is null begin raiserror(@noBackupErrorMessage, 16, 1) end
RESTORE VERIFYONLY FROM DISK = @fileName WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
FETCH NEXT FROM db_cursor INTO @name
END
CLOSE db_cursor
DEALLOCATE db_cursor
НО, если вы используете JungleDisk, вы можете обнаружить, что цепочка резервного копирования нарушена, и вы не можете создавать дифференциальные резервные копии!
Защита данных SQL Server начинается с дисков - вы размещаете файлы данных на выделенных дисках RAID (в идеале RAID10), помещаете файлы журнала транзакций на другой диск RAID10 и TEMPDB в другое место. Это сделано по соображениям производительности, но также и для восстановления: если один из дисков выйдет из строя, у вас есть шанс. RAID должен позволять восстановление, но также, если ваш диск данных вышел из строя, вы должны иметь возможность получить последние транзакции из журнала транзакций.
Затем идут резервные копии SQL Server - они должны быть перенесены на отдельный диск, а затем сняты с сервера либо на ленту, либо на другой удаленный сервер. В зависимости от размера баз данных и периодов обслуживания может быть целесообразным ежедневное полное резервное копирование или еженедельное полное резервное копирование. Вдобавок к этому делайте частые резервные копии журнала транзакций (возможно, ежечасно), а также, возможно, различия в зависимости от размера ваших баз данных.
Заключительная часть - проверка. Часто проверяйте свои восстановления, фактически выполняя восстановление в другом месте. Убедитесь, что резервные копии каким-то образом уходят за пределы сайта. Тестовый тестовый тест