-
- Veteran
- Posts: 1267
- Liked: 455 times
- Joined: Dec 17, 2015 7:17 am
- Contact:
Moving > 1 PB of Backup files to a new storage
Hello,
we are currently planning to move all our backup files of one Veeam system (slightly more than 1 PB) to a new flash based storage. Our main issue is that we cannot afford to loose log backup for more than 1-2 hours. Moving backup of database servers > 10 TB might take longer.
Would the following work?
- adding the SQL Server to a new Job without transaction log backup
- active full of the new job
- excluding the VM from the old job
- enabling transaction log backup on the new job
Is setting SqlBackupLogsAgeDaysToSkipLogBackup and SqlBackupLogsAgeDaysToSkipTruncate to 0 still needed or is there another option in 12.2 (by the way - great release!)?
Markus
we are currently planning to move all our backup files of one Veeam system (slightly more than 1 PB) to a new flash based storage. Our main issue is that we cannot afford to loose log backup for more than 1-2 hours. Moving backup of database servers > 10 TB might take longer.
Would the following work?
- adding the SQL Server to a new Job without transaction log backup
- active full of the new job
- excluding the VM from the old job
- enabling transaction log backup on the new job
Is setting SqlBackupLogsAgeDaysToSkipLogBackup and SqlBackupLogsAgeDaysToSkipTruncate to 0 still needed or is there another option in 12.2 (by the way - great release!)?
Markus
-
- Enthusiast
- Posts: 26
- Liked: 7 times
- Joined: Jun 09, 2023 12:47 pm
- Full Name: JGM
- Contact:
Re: Moving > 1 PB of Backup files to a new storage
This should work absolutely fine as far as I am aware - This Is how It was completed In 12.1
-
- Veeam Software
- Posts: 2801
- Liked: 639 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Moving > 1 PB of Backup files to a new storage
Hi mkretzer,
I think your plan makes the most sense with the least disruption for your log backups. The only additional idea I would suggest is if Backup Move for just the jobs with SQL Log Backups would work without disrupting your log backup scheme; depending on your configuration, this might not be suitable and will still include disruption, but wanted to ensure the option was not missed.
Else, your idea makes sense, and following our KB here to change which job controls the log backups is the correct procedure.
I think your plan makes the most sense with the least disruption for your log backups. The only additional idea I would suggest is if Backup Move for just the jobs with SQL Log Backups would work without disrupting your log backup scheme; depending on your configuration, this might not be suitable and will still include disruption, but wanted to ensure the option was not missed.
Else, your idea makes sense, and following our KB here to change which job controls the log backups is the correct procedure.
David Domask | Product Management: Principal Analyst
-
- Veteran
- Posts: 1267
- Liked: 455 times
- Joined: Dec 17, 2015 7:17 am
- Contact:
Re: Moving > 1 PB of Backup files to a new storage
But how would backup move work? Would it not disable log processing for the whole time of the backup move?
-
- Veeam Software
- Posts: 2801
- Liked: 639 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Moving > 1 PB of Backup files to a new storage
Hi mkretzer,
Correct, which is why mentioned that it does heavily depend on your configuration and also just the overall speed of the move operation. Unfortunately since all such operations will depend on environmental factors for the total transfer time, I did not want to propose it was a perfect solution, but just one option if you can perform the move without disrupting your log backup scheme. From what I remember on your descriptions of your environment from previous posts, I'm not 100% confident it would meet your needs here, so it was more a reminder for something to consider besides your original idea. If Backup Move will be able to meet your requirements, then it saves a bit of time and effort, and if not, then you still have the original idea to utilize.
Correct, which is why mentioned that it does heavily depend on your configuration and also just the overall speed of the move operation. Unfortunately since all such operations will depend on environmental factors for the total transfer time, I did not want to propose it was a perfect solution, but just one option if you can perform the move without disrupting your log backup scheme. From what I remember on your descriptions of your environment from previous posts, I'm not 100% confident it would meet your needs here, so it was more a reminder for something to consider besides your original idea. If Backup Move will be able to meet your requirements, then it saves a bit of time and effort, and if not, then you still have the original idea to utilize.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Amazon [Bot], Google [Bot] and 25 guests