Hi, On 11/01/2016 10:37 AM, Gandalf Corvotempesta wrote: > 2016-11-01 9:26 GMT+01:00 Adam Goryachev > <[email protected]>: >> Easy, configure your keepfull/incremental and your full/incremental >> periods so that they will match your desired retention periods for your >> needs. >> >> Make sure you use rsync (ie, same as rsnapshot). >> >> Use checksum caching
This is not yet implemented in BackupPC 4, so full are still slow. See: https://github.com/backuppc/backuppc/issues/32 >> Then, after your second full backup, you see the time to complete a >> backup is similar to an incremental. > > Any drawback doing this like rsnapshot ? > What happens if I delete the "full" backup ? In BackupPC 4, deleting a full backup is the same as deleting an incremental one - it is merged to the next backup. It should be very fast unless it is a filled one. You need to use BackupPC_backupDelete for this to manage the merging properly. Note that in v4, full and filled concepts are decoupled, where full means that all file content is checked and filled means that the BackupPC pc/[backupnumber] folder for the host carries the complete list of files and folders in it. > With rsnapshot nothing happens, by using hardlinks, the only way to > loose backus (and data) > is to delete all hardlinks pointing to a file, so I have to delete the > whole backup pool > > What about backuppc ? a new full is made if the previous full is lost > or the first "useful" backup is promoted to full ? I'd consider this a pool integrity thing. If you somehow manage to delete the actual files in your BackupPC pool, its integrity is compromised in the same way as tampering with hard links for rsnapshot. BackupPC v4 works quite differently though, since file content (cpool) and backups (pc) are not hardlinked. It is more of a "database and shared storage objects" model, with the "database" being a mix of directory structures, file indexes and reference counts. Currently v4 does seem to check the pool file on every backup and thus will recover nicely. All backups are promoted to filled when running anyway. However, I am a proponent of having BackupPC v4 _dump never checking the pool (cpool), unless there is an unavoidable condition (such as a checksum collision detection, block comparison or a v3 style checksum recheck probability). The reason is that this would immensely speed up backups and enable the use of higher latency cloud storage systems (object/API based or mounted) such as swift or glusterfs. Checking could be decoupled from backups through the use of a separate storage integrity checker (think a nightly job or a slow crawler). This way, cpool growth I/O + possible integrity checks, rather than every backup, would cap BackupPC performance. Considering the lack of checksum caching, the extra test fscks mentioned earlier, and the above mentioned extra pool checks during backup, BackupPC v4 is still a bit slow with large backups. > I'm asking this because based on the answer I can try to get the best > config for my environment. If BPC is smart enough > to work even without the original full, I can use a full period very > very high (like 1 year) > Changes in BackupPC 4 are especially geared towards allowing very high full periods. The most recent backup being always filled (as opposed to rsnapshots hardlink pointing to the first), a full backup is not required to maintain a recent and complete representation of all the files and folders. Best regards, Johan ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
