Full and incremental backups issue using vbr.py on Vertica 6.1.2

Ben_Haworth

Hi I'm trying to set up a daily incremental backup, but having run this manually twice, I've ended up with both a full backup (expected) plus an incremental which appears to be a full backup also. My config file reads as follows: [Misc] snapshotName = data_services_backup verticaConfig = True restorePointLimit = 7 [Database] dbName = DATA_SERVICES dbUser = dbadmin dbPassword = nEPRexe2 [Transmission] [Mapping0] dbNode = v_data_services_node0001 backupHost = elinkvertica01 backupDir = /vertica_db/backup I have the following two folders in my backup directory: data_services_backup (128,386,088 bytes) data_services_backup_archive20130805_111547 (126,960,996 bytes) Have I missed something in the configuration? I'm also somewhat surprised the the more recent backup, while a similar size, is just a bit smaller. So perhaps it is an incremental, and I'm missing what the increment actually is. I know that very little additional data has been added to the database between backups as I've done the only additions myself. Thanks for your help. Ben

Bhawana

Hi Ben, I will test this in our in house environment and get back to you. -Bhawana

Ben_Haworth

Great, thanks. Any possible advice from others in the meantime would be appreciated. I'll be back onto this myself now this afternoon!

Bhawana

Hi Ben, It seems like both directories are same size but it is not. Run this command to see the actual size: du -ahb --max-depth=1 Regards, Bhawana

Ben_Haworth

Hi Bhawana They're not exactly the same size, but they are very similar. The output of your command shows as below, and from this I can see that there is a difference of a couple of Gb. This appears nonsensical [root@elinkvertica01 data_services_backup]# du -ahb --max-depth=1 171 ./data_services_backup.info 131237997671 ./vertica_db 461 ./data_services_backup.txt 131238002399 . [root@elinkvertica01 data_services_backup_archive20130805_111547]# du -ahb --max-depth=1 171 ./data_services_backup.info 129778100300 ./vertica_db 460 ./data_services_backup.txt 129778105027 . I have just tried running another two incremental backups, the commands used are below, and the output on disk utilisation is after that. There has been no change to the databases in between these two successive backups, and therefore no reason to account for any change in disk utilisation. [dbadmin@elinkvertica01 bin]$ vbr.py --task backup --config-file data_services_b ackup.ini Preparing... Found Database port: 5433 Copying... [==================================================] 100% All child processes terminated successfully. Committing changes on all backup sites... backup done! [dbadmin@elinkvertica01 v_data_services_node0001]$ cd data_services_backup [dbadmin@elinkvertica01 data_services_backup]$ du -ahb --max-depth=1 171 ./data_services_backup.info 131601656445 ./vertica_db 461 ./data_services_backup.txt 131601661173 . [dbadmin@elinkvertica01 data_services_backup_archive20130808_091631]$ du -ahb --max-depth=1 171 ./data_services_backup.info 131601656050 ./vertica_db 461 ./data_services_backup.txt 131601660778 . So, there still seems to be two full backups, even when done in rapid succession with no changes in the db itself. Thanks for your help on this though, I'm totally new to Vertica so this is a difficult one to unpick myself! Ben

Ben_Haworth

Hi Bhawana (and anybody else who is interested) Having spoken to our Linux support people, an alternative command of du -sh * was suggested, and this has shown us that there are indeed increments. What appears to be counted each time is the hard links in the archives back to the latest backup. [root@elinkvertica01 v_data_services_node0001]# du -sh * 123G data_services_backup 2.0G data_services_backup_archive20130805_111547 279M data_services_backup_archive20130806_095739 281M data_services_backup_archive20130808_091631 So, I can see now what's happening in terms of the increments. Now we've understood this, it does however raised a different question which I'm going to post separately, regarding potential for corruption of the database in the latest backup. Thanks Ben