Hey, I just relearned something. I completely forgot about -r doing the
refcountupdate!
Cheers,
mph
> On May 21, 2017, at 9:42 PM, Craig Barratt
> wrote:
>
> Alex,
>
> You didn't answer my question.
>
> It should be ok to use BackupPC_backupDelete as
delete some servers backup.
looks good
will wait for next maintenance.
thanks one more time Craig
nice product
Alex
On 22 May 2017 at 12:44, Alexey Safonov wrote:
> ah... sorry.
>
> now i clearly understand. many thanks, Craig
>
> Alex
>
> On 22 May 2017 at 12:42,
ah... sorry.
now i clearly understand. many thanks, Craig
Alex
On 22 May 2017 at 12:42, Craig Barratt
wrote:
> Alex,
>
> You didn't answer my question.
>
> It should be ok to use BackupPC_backupDelete as Michael suggested, even
> without taking a new full
Alex,
You didn't answer my question.
It should be ok to use BackupPC_backupDelete as Michael suggested, even
without taking a new full backup. I recommend using the -r option, which
will re-run BackupPC_refCountUpdate:
su backuppcUser
BackupPC_backupDelete -h HOST -n 134 -r
It will merge
sorry? what do you mean?
let me try full backup first and then wait for night maintenance. but i'm
sure that pool size will be same as that not needed files was backed up and
now will be in pool for history.
for me it's not big problem as i have free size in pool and can wait 8
weeks (our backup
Can we stick to the backups with #133, #134, #135?
Cheers!
mph
On 2017-05-21 21:19, Alexey Safonov wrote:
> here is one real example
>
> 321 incr num of files = 131074
> 322 incr num of files = 774220 (because of error ib backupfilesonly)
> 324 incr num of files 130946 (after applying
here is one real example
321 incr num of files = 131074
322 incr num of files = 774220 (because of error ib backupfilesonly)
324 incr num of files 130946 (after applying hotfix)
and i can see graph on main page that show usage of pool ~3 times higher
than regular. so now i'm looking how to
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
Is 134 large because it included additional directories or files that are
not in 133 or 135?
Is backup 133 filled?
Craig
On Sun, May 21, 2017 at 8:49 PM, Alexey Safonov
wrote:
> but if i do full backup for example 135 it will copy existing 134 and then
> do diff
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
Ah, ok. I would run a Full backup (now considered "Filled"). That's
the safest move prior to removing 134. The most recent backup is always
Filled, but were talking about important data so I don't see a problem
with doing on more Full (Filled) backup to ensure safety.
Craig - anything wrong
Thanks for quick reply.
but as i understan in V4 full backup in last folder. My question is related
to bug in 4.1.2 (that is now fixed). But because of that bug i have regular
backup 133 , abnormal backup 134 (it's huge in size) and again normal
backup 135
i need to really cleanup my NFS storage.
I would strongly suggest the use of BackupPC_backupDelete -n 134 to
properly remove the backup. It should be fine to remove. You'll lose
whatever changes occurred between 133 and 134.
Cheers,
mph
On 2017-05-21 19:36, Alexey Safonov wrote:
> Hi, All
>
> I'm usinv V4 backuppc. is it safe
Hi, All
I'm usinv V4 backuppc. is it safe to delete one intermediate backup? for
example we have in /pc/litspc123 dirs 133 135 and 135
is it safe to delete backup 134 directly from nfs?
Alex
--
Check out the vibrant
14 matches
Mail list logo