|
Yes v4 is more complex. Each new backup is filled (copied forward) which is kinda like a full backup - but a moving full backup, as BackupPC calculates the diff from the prior backups. If 135 is leaner (smaller) than 134 then BackupPC has already figured out what is going on. By creating a semi-permanent filled backup through a Full backup for #136, then using BackupPC_deleteBackup, BackupPC should properly calculate what needs to remain within the pool when removing #134 (files associated with an attrib remain). Orphaned files within the pool should be removed over time.
So if the pool is filled with files only associated with backup #134 and not tied to other backups you should be fine. Nightly maintenance should remove them.
Thought experiment (I think this is where you are going):
If #134 is treated like a new, original backup (as if all previous backups didn't exist) and #135 is based off that backup we have an interesting question to think about. Would BackupPC leave many of the files behind with Filled #136? If you remove #134 via BackupPC_deleteBackup will many files remain because they are tied to #135? My thought is yes. But only if BackupPC thinks #134 is an original backup.
The answer then would be to remove #134 and #135. Yes you lose two days of backups but you regain sanity and backup space. This may be your best solution however unhappy it may make you.
Cheers!
mph
On 2017-05-21 20:49, Alexey Safonov wrote:
but if i do full backup for example 135 it will copy existing 134 and then do diff into 134
that's new in V4
so there are no way to delete data that was backup by mistake and preserver history.
V4 is good one but more complex according to V3.
and now i have 500GB used on /mnt/backup (and regular was about 100-1500GB :)
Alex
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
| 