On Mon, Oct 3, 2011 at 12:54 PM, Holger Parplies wrote:
>
> 1.) Merging of pools. Actually quite easy.
I think everything I've done so far in terms of copying existing data
would have worked out if I could rsync -H individual pc trees and then
somehow relink to recreate the pool, hopefully as an
Hi,
Jeffrey J. Kosowsky wrote on 2011-10-02 23:37:07 -0400 [Re: [BackupPC-users]
Fairly large backuppc pool (4TB) moved with(TAB)backuppc_tarpccopy]:
> > My method has the downside that you need to sort a huge file (but the
> > 'sort' command handles huge files rather well). Jeffrey's method ha
Holger Parplies wrote at about 04:48:10 +0200 on Monday, October 3, 2011:
> You might want to use parts of either Jeffrey's or my script. Jeffrey builds
> a
> "pool" of information which files use which inode. I build a file with pretty
> much the same information. Both don't need to be stored
Hi,
Mike Dresser wrote on 2011-10-02 21:26:05 -0400 [Re: [BackupPC-users] Fairly
large backuppc pool (4TB) moved with backuppc_tarpccopy]:
> On Mon, 3 Oct 2011, Holger Parplies wrote:
> > This was on the *old* pool, right?
>
> I thought it was. But now that I look again and they
On Mon, 3 Oct 2011, Holger Parplies wrote:
> almost all. Zero-length files are not pooled, so they will have a link count
> of 1. Anything else below pc/host/nn should have at least two links (including
> directories :).
Ok, that explains my sockets being nlink of 1.. They're 0 byte :)
Hi,
Mike Dresser wrote on 2011-10-02 21:35:52 -0400 [Re: [BackupPC-users] Fairly
large backuppc pool (4TB) moved with backuppc_tarpccopy]:
> [...]
> Should all my fmangled files have an nlink over 1?
almost all. Zero-length files are not pooled, so they will have a link count
of 1. An
On Sun, 2 Oct 2011, Jeffrey J. Kosowsky wrote:
> 2 follow-ups would be helpful:
> 1. Is this true for the other non-top-level attrib files?
> 2. Are the other f-mangled files in the directory also only have a
> single link?
> This would happen if there is a problem in the linking stage. In
>
On Mon, 3 Oct 2011, Holger Parplies wrote:
> This was on the *old* pool, right?
I thought it was. But now that I look again and they're all showing 2 on
the nlink.. I think I'm losing my marbles, or I was looking at the new
pool. Sorry!
> Does the XferLOG for the backup the attrib file is in
Mike Dresser wrote at about 15:44:32 -0400 on Sunday, October 2, 2011:
> On Sun, 2 Oct 2011, Jeffrey J. Kosowsky wrote:
>
> > If you want to troubleshoot, I would do the following:
>
> I'm currently running 3.1.0, so that probably answers why I'm seeing
> these. Thought I was on 3.2 for s
On Sun, Oct 2, 2011 at 6:04 PM, Holger Parplies wrote:
> no, BackupPC is implemented in Perl, so no libc dependency there (actually,
> the wheezy package *does* introduce a libc6 dependency, ">= 2.0" seems to mean
> you can't run it on Debian versions prior to hamm :-); I'm not sure why the
> depe
Hi,
Mike Dresser wrote on 2011-10-02 15:44:32 -0400 [Re: [BackupPC-users] Fairly
large backuppc pool (4TB) moved with backuppc_tarpccopy]:
> I'm currently running 3.1.0, so that probably answers why I'm seeing
> these. Thought I was on 3.2 for some reason, I might try dpkg -i
On Sun, 2 Oct 2011, Jeffrey J. Kosowsky wrote:
> If you want to troubleshoot, I would do the following:
I'm currently running 3.1.0, so that probably answers why I'm seeing
these. Thought I was on 3.2 for some reason, I might try dpkg -i'ing in
3.2.1 from wheezy(testing) on a test system and s
On Sun, 2 Oct 2011, Jeffrey J. Kosowsky wrote:
> https://sourceforge.net/apps/mediawiki/backuppc/index.php?title=BackupPC_CopyPcPool
Thank you, I've even seen that script before, mental brain fart as to why
I didn't investigate it this time around...
I have another server I might be migrating s
Mike Dresser wrote at about 10:51:14 -0400 on Sunday, October 2, 2011:
> Can you point me to those? My method was to rsync the everything but the
> pc dir, and then used backuppc_tarpccopy to create a tar file of the
> hardlinks.. I probably could have saved a few days by directly extracting
Holger Parplies wrote at about 05:39:15 +0200 on Sunday, October 2, 2011:
> Mike Dresser wrote on 2011-09-29 14:11:20 -0400 [[BackupPC-users] Fairly
> large backuppc pool (4TB) moved with backuppc_tarpccopy]:
> > [...] Did see a few errors, all of them were related to the
On Sun, 2 Oct 2011, Holger Parplies wrote:
>> Out of curiosity, where are those errors (the attrib in pool ones)
>> coming from?
> your quote above does *not* reference a *top-level* attrib file (that would be
> "xx/116/attrib"), and, beyond that, you don't seem to have multiple shares,
> so it m
Hi,
Mike Dresser wrote on 2011-09-29 14:11:20 -0400 [[BackupPC-users] Fairly large
backuppc pool (4TB) moved with backuppc_tarpccopy]:
> [...]
> Old disks were 10 x 1TB in raid10, new is 6 x 3TB's in raid6 (which in
> itself has been upgraded many times).. the new raid6 is FAR fas
Hi,
Tim Connors wrote on 2011-10-01 14:22:13 +1000 [Re: [BackupPC-users] Fairly
large backuppc pool (4TB) moved with backuppc_tarpccopy]:
> [...]
> It's all too tricky. I'm going back to clay tablets.
I've looked into the matter and couldn't find any which support har
On Fri, 30 Sep 2011, Mike Dresser wrote:
> On 29/09/11 10:28 PM, Adam Goryachev wrote:
> > Can I assume this is because the new HDD's perform better than the old?
> > In other words, would it be safe to assume you would get even better
> > performance using RAID10 with the new HDD's than you are g
On Fri, Sep 30, 2011 at 2:16 PM, Mike Dresser
wrote:
>
> Either way, the system keeps up with backups, so performance wasn't much
> of an issue, I just plain ran out of space on the old array.
>
> Also, with 6-8 drives, I can lose any two, vs the remote possibility of
> losing the wrong two on Rai
On 29/09/11 10:28 PM, Adam Goryachev wrote:
> Can I assume this is because the new HDD's perform better than the old?
> In other words, would it be safe to assume you would get even better
> performance using RAID10 with the new HDD's than you are getting with RAID6?
Yes, the new drives are severa
On Friday 30 September 2011 14:37:20 Les Mikesell wrote:
> On Fri, Sep 30, 2011 at 5:51 AM, Arnold Krille wrote:
> > And don't argue that disks with consecutive serial numbers won't break
> > together: From the three disk failures I encountered where I had a second
> > of the same type, that secon
On 2011-09-30 14:37, Les Mikesell wrote:
> For software raid, I thought a cron job was
> supposed to be testing them periodically, but the notification may not
> reach you - and hardware raid may not to the tests.
Ubuntu has a job in cron.monthly which does a full check of all md RAID
arrays. It r
On Fri, Sep 30, 2011 at 5:51 AM, Arnold Krille wrote:
>
> And don't argue that disks with consecutive serial numbers won't break
> together: From the three disk failures I encountered where I had a second of
> the same type, that second broke shortly after.
>
I'd argue that it is not likely that
On 2011-09-30 12:51, Arnold Krille wrote:
> Thats stupid.
>
> Raid5: Loose one disk during recovery -> you are screwed.
> Raid6: Loose two disks during recovery -> you are screwed.
Further:
Raid5: Lose power during write operation = silent data corruption, which
you'll find out about next time y
On Friday 30 September 2011 06:20:42 Tim Connors wrote:
> Worst case, if you lose one disk, then rebuild, and during rebuild,
> suffer the likely consequence of losing another disk when rebuilding
> raid6, you still have a valid array.
> Worse case, fairly likely occurence with raid10, lose that se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/09/11 14:20, Tim Connors wrote:
> On Fri, 30 Sep 2011, Adam Goryachev wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 30/09/11 04:11, Mike Dresser wrote:
>>> Just finishing up moving one of my backuppc servers to new larger
On Fri, 30 Sep 2011, Adam Goryachev wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 30/09/11 04:11, Mike Dresser wrote:
> > Just finishing up moving one of my backuppc servers to new larger disks,
> > and figured I'd submit a success story with backuppc_tarpccopy... I
> > wanted to
On Thu, Sep 29, 2011 at 9:28 PM, Adam Goryachev <
mailingli...@websitemanagers.com.au> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 30/09/11 04:11, Mike Dresser wrote:
> > Just finishing up moving one of my backuppc servers to new larger disks,
> > and figured I'd submit a succe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/09/11 04:11, Mike Dresser wrote:
> Just finishing up moving one of my backuppc servers to new larger disks,
> and figured I'd submit a success story with backuppc_tarpccopy... I
> wanted to create a new xfs filesystem rather than my usual dd an
Just finishing up moving one of my backuppc servers to new larger disks,
and figured I'd submit a success story with backuppc_tarpccopy... I
wanted to create a new xfs filesystem rather than my usual dd and
xfsgrowfs, as this thing has been in use since backuppc 2.1 or similar.
Old disks were
31 matches
Mail list logo
