-
- Veteran
- Posts: 527
- Liked: 58 times
- Joined: Jun 06, 2018 5:41 am
- Full Name: Per Jonsson
- Location: Sweden
- Contact:
Changes in source backup files detected, rescan required
Folks,
Sometimes when I do a backup to tape, I get this message:
"Changes in source backup files detected, rescan required"
What happens then, exactly. Does it start over with that particular source backup? If so, what happens with the data that it has already written to tape from that source?
PJ
Sometimes when I do a backup to tape, I get this message:
"Changes in source backup files detected, rescan required"
What happens then, exactly. Does it start over with that particular source backup? If so, what happens with the data that it has already written to tape from that source?
PJ
-
- Veeam Vanguard
- Posts: 638
- Liked: 154 times
- Joined: Aug 13, 2014 6:03 pm
- Full Name: Chris Childerhose
- Location: Toronto, ON
- Contact:
Re: Changes in source backup files detected, rescan required
This just means it needs to rescan your repo to update the Veeam DB. It should continue on with the same files. Also, be sure the main backup job is not running at the same time as the tape job so they will not conflict.
-----------------------
Chris Childerhose
Veeam Vanguard / Veeam Legend / Veeam Ceritified Architect / VMCE
vExpert / VCAP-DCA / VCP8 / MCITP
Personal blog: https://just-virtualization.tech
Twitter: @cchilderhose
Chris Childerhose
Veeam Vanguard / Veeam Legend / Veeam Ceritified Architect / VMCE
vExpert / VCAP-DCA / VCP8 / MCITP
Personal blog: https://just-virtualization.tech
Twitter: @cchilderhose
-
- Veeam Software
- Posts: 2123
- Liked: 513 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Changes in source backup files detected, rescan required
Hey all,
Small correction @chris.childerhose, I think what Per is seeing is that during the Tape Job, the source job has run and the tape job needs to re-check the source job to make sure the candidate it picked for tape-out is still valid.
Tape generally works like the following:
1. Job launches
2. Tape-out options are loaded into the logic (GFS day, should we backup latest chain only or all, what is the minimum storage creation date accepted, etc)
3. All source items are checked for their candidacy for tape-out (e.g., does the source backup chain have a candidate which meets the GFS interval, have we tape-out-ed this backup already, etc)
4. The candidate list is passed to the tape processor.
5. Media pool is selected and the correct valid tape medium is chosen for writing
6. The individual source job task starts
7. Because there might be a delay or a change in the source job during the candidate selection and the task starting, we check the chain once more at the start of the tape task to make sure our candidate is still valid
8. If all is good, tape-out the backup file(s)
9. Check again at the end of the tape-out and see if the source job has changed, and depending on some settings, requeue the source backup for candidate selection
My guess is that what Per is seeing is that during the 7 and 9, the source job has run and the backup chain is now different. We need to double-check that what we wrote to tape is still valid and has a legal chain for restore. This is normal. With v10 and later, we typically don't requeue tasks that already have had a successful tape-out. (There are _very_ few exceptions to this, but they are really far out edge cases).
So in fact, very little needs to be done with this -- the tape job logic is just making sure that we have on tape valid chains and we haven't missed any essential backups that need to be on tape for restore purposes.
Small correction @chris.childerhose, I think what Per is seeing is that during the Tape Job, the source job has run and the tape job needs to re-check the source job to make sure the candidate it picked for tape-out is still valid.
Tape generally works like the following:
1. Job launches
2. Tape-out options are loaded into the logic (GFS day, should we backup latest chain only or all, what is the minimum storage creation date accepted, etc)
3. All source items are checked for their candidacy for tape-out (e.g., does the source backup chain have a candidate which meets the GFS interval, have we tape-out-ed this backup already, etc)
4. The candidate list is passed to the tape processor.
5. Media pool is selected and the correct valid tape medium is chosen for writing
6. The individual source job task starts
7. Because there might be a delay or a change in the source job during the candidate selection and the task starting, we check the chain once more at the start of the tape task to make sure our candidate is still valid
8. If all is good, tape-out the backup file(s)
9. Check again at the end of the tape-out and see if the source job has changed, and depending on some settings, requeue the source backup for candidate selection
My guess is that what Per is seeing is that during the 7 and 9, the source job has run and the backup chain is now different. We need to double-check that what we wrote to tape is still valid and has a legal chain for restore. This is normal. With v10 and later, we typically don't requeue tasks that already have had a successful tape-out. (There are _very_ few exceptions to this, but they are really far out edge cases).
So in fact, very little needs to be done with this -- the tape job logic is just making sure that we have on tape valid chains and we haven't missed any essential backups that need to be on tape for restore purposes.
David Domask | Product Management: Principal Analyst
-
- Veteran
- Posts: 527
- Liked: 58 times
- Joined: Jun 06, 2018 5:41 am
- Full Name: Per Jonsson
- Location: Sweden
- Contact:
Re: Changes in source backup files detected, rescan required
Thank you very much!
Kind regards,
PJ
Kind regards,
PJ
-
- Veeam Vanguard
- Posts: 638
- Liked: 154 times
- Joined: Aug 13, 2014 6:03 pm
- Full Name: Chris Childerhose
- Location: Toronto, ON
- Contact:
Re: Changes in source backup files detected, rescan required
Thanks for the correction David!
-----------------------
Chris Childerhose
Veeam Vanguard / Veeam Legend / Veeam Ceritified Architect / VMCE
vExpert / VCAP-DCA / VCP8 / MCITP
Personal blog: https://just-virtualization.tech
Twitter: @cchilderhose
Chris Childerhose
Veeam Vanguard / Veeam Legend / Veeam Ceritified Architect / VMCE
vExpert / VCAP-DCA / VCP8 / MCITP
Personal blog: https://just-virtualization.tech
Twitter: @cchilderhose
Who is online
Users browsing this forum: No registered users and 10 guests