New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nbackup RDB$BACKUP_HISTORY cleanup #7186
Comments
What is the real problem ? Few hundreds of records ? Looks strange for me ;) Anyway, I see following possible ways to keep less records in RDB$BACKUP_HISTORY:
Another ideas ? |
Sorry, these two options is no go - nbackup should be able to find SCN of prior backup.
...and this one also looks suspicious. |
Imagine a backup every minute of hundreds of databases over 5 years or more. |
Number of databases doesn't matters, as RDB$BACKUP_HISTORY is per-database. Anyway, I already offered some solution and asked for another (better) ideas. |
Isn't it enough to keep exactly one record per each backup level? AFAIU since you have made backup of level X, subsequent backups of level X+1 can be based only on this snapshot so other backups of level X become irrelevant (or unusable). |
@aafemt you are wrong |
Let me clarify a bit
Only in case of GUID-based backup
This statement is completely wrong |
Sorry for being unclear. I understand RDB$BACKUP_HISTORY is per database. |
I learned that the initial nbackup of initial database require switch -B 0 (level) and after that GUID is supplied instead of level. NBACKUP -BG 0 -> initial backup. First GUID is created |
Apologies, maybe I'm out of line but I need to ask if is there hope that this issue might be addressed? |
I still have no better ideas than
Opinions ? |
This will break non-GUID based backup's of this database. Also, with backup history you may produce backup based on any known\existing prior backup. |
Both suggestions are great! |
The proposition is following:
Items to discuss:
|
CLEAN_HISTORY. Is it not the case that all rows beyond last N0 irrelevant? Maybe default can be delete all beyond last N0. If GUID only last nbackup is relevant? |
What is good for you is not necessary good for everyone. If you not use nbackup for backup purpose alongside with cold "standby" - it doesn't mean we should by default destroy ability to do it. With proposition above you can keep one row in RDB$BACKUP_HISTORY if you strongly need that. But don't force dangerous behaviour for every one, please. |
Implementation is committed, please test next snapshot build. |
Excellent! |
Old link for snapshot builds works now: If it will not work tomorrow, follow instructions here: note, you need build of branch v4.0-release |
The build works and I'm testing it :) What about cleaning records without creating an actual nbackup? I think it might be useful. nbackup -CLEAN_HIST -KEEP_R 2 -U SYSDBA -P PASSKEY TESTDB.FDB |
Thanks for testing. As for "cleaning records without creating an actual nbackup" - now you may run isql and delete anything you want. |
Has this code landed in master as well? If not, when will it be added there? |
I'm preparing a change for command-line syntax, it will be committed into v4 and then into master, if there will be no objections. |
Replace command-line switches -KEEP_DAYS and -KEEP_ROWS by single switch -KEEP <N> DAYS|ROWS as suggested by Dimitry Sibiryakov Add some docs.
I've committed some changes, now the command line syntax is as follows:
Usage notes:
Services API appended with with new parameter tags for
Examples
nbackup -B 1 db.fdb db.nbk -clean_hist -keep 1 row fbsvcmgr action_nbak dbfile db.fdb nbk_file db.nbk nbk_level 1 nbk_clean_history nbk_keep_rows 1
nbackup -clean_hist -keep 7 d -B 2 db.fdb db.nbk fbsvcmgr action_nbak dbfile db.fdb nbk_file db.nbk nbk_level 2 nbk_clean_history nbk_keep_days 7 |
Hello,
The FB4 GUID based nbackup and incremental restore are huge improvement and we would like to use it as an convent way for replica solution.
What makes it convenient, compared to the actual Replica functions is the zero need of configuration both on server and client side, which is a must since we have many hundreds of database files, and databases are created on the fly.
The issue with making nbackups very often is that the RDB$BACKUP_HISTORY will be flooded with records that is read-only.
I guess with GUID based nbackup it's not necessary to store all history since start of first nbackup.
There should be a way to delete these records, or when GUID nbackaup is executed old unnecessary records are automatically deleted.
The text was updated successfully, but these errors were encountered: