[chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
I've updated http://crbug.com/25959 with some comments. The suggestion was made to exclude the entire profile directory as a short-term solution, but that would mean not backing up the bookmarks and cookies. So for the immediate need (M4) what is more important: a) saving space in the Time Machine volume, or b) having a backup of bookmarks and cookies? On Nov 9, 7:40 pm, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM,mrossettiwrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
On Tue, Nov 10, 2009 at 08:14, mrossetti mrosse...@chromium.org wrote: I've updated http://crbug.com/25959 with some comments. The suggestion was made to exclude the entire profile directory as a short-term solution, but that would mean not backing up the bookmarks and cookies. So for the immediate need (M4) what is more important: a) saving space in the Time Machine volume, or b) having a backup of bookmarks and cookies? a is more important. On Nov 9, 7:40 pm, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM,mrossettiwrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
I've verified with SQLite that journal files do NOT get the sync cookie. We could consider adding it to our SQLite, I suppose. It looks like there is room in the journal header for things like that. Not sure how often it comes up, but if it does come up it would be pretty devastating. -scott On Mon, Nov 9, 2009 at 6:40 PM, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM, mrossetti wrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
On Nov 6, 2009, at 10:09 AM, mrossetti wrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM, mrossetti wrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
