Les Mikesell writes:
On Fri, 2006-01-20 at 16:44, Dan Pritts wrote:
On Fri, Jan 20, 2006 at 03:53:33PM -0600, Les Mikesell wrote:
I'd expect to see quite a lot of temp file activity that would
result in changes to unused space on the live system. It would
Yeah, you're right - i
Message-
From: Justin R. Pessa [EMAIL PROTECTED]
To: Tim Chipman [EMAIL PROTECTED]
Date: Thu, 19 Jan 2006 17:20:26 -0500
Subject: Re: [BackupPC-users] Q: Offsite copy-backup to removable SATA HotSwap
LVM Sets?
Tim,
My backup pool is much smaller, but what I do is very similar.
I've got 2
On Fri, 2006-01-20 at 08:07, Justin R. Pessa wrote:
No problem! Like you, I spent a while trying to wrap my head around the
way I was running BackupPC, to make certain it was a realistic
procedure. I'm glad to see others have come to use similar methods!
If you browse through the list
On Thu, Jan 19, 2006 at 02:28:09PM -0500, Tim Chipman wrote:
Additionally, I suppose - based on how quick the data pool evolves, rsync
could be used to update the (rotating disk pool raid5 data) which might
be faster than doing (reformat and clean copy) each week. Or maybe not.
given the
On Fri, Jan 20, 2006 at 11:37:14AM -0600, Les Mikesell wrote:
I don't think it will be practical to let one backuppc system
back up another, although I've always wished it could for
a similar scenario where the 'sub' levels are in remote
offices. I think it could be made to work but would
On Fri, 2006-01-20 at 13:54, Dan Pritts wrote:
I don't think it will be practical to let one backuppc system
back up another, although I've always wished it could for
a similar scenario where the 'sub' levels are in remote
offices. I think it could be made to work but would require
On Fri, Jan 20, 2006 at 02:10:12PM -0600, Les Mikesell wrote:
The number of hardlinks makes rsync (or other file-oriented) copies
impractical if the archive is large at all,
It occurs to me that you could, rather than rsyncing at the filesystem,
rsync the raw device that holds the filesystem.
On Fri, 2006-01-20 at 14:22, Dan Pritts wrote:
The number of hardlinks makes rsync (or other file-oriented) copies
impractical if the archive is large at all,
It occurs to me that you could, rather than rsyncing at the filesystem,
rsync the raw device that holds the filesystem. That
On Fri, Jan 20, 2006 at 03:03:00PM -0600, Les Mikesell wrote:
I think the same idea occurred to me a while back but rsync
refused to use a device directly.
Annoying. Could be patched in rsync, though. I bet that
Wayne would consider an option to do this.
You'd probably want to fill
all
On Fri, Jan 20, 2006 at 03:53:33PM -0600, Les Mikesell wrote:
I'd expect to see quite a lot of temp file activity that would
result in changes to unused space on the live system. It would
Yeah, you're right - i think of this as all being rsync based
but it sort of is and sort of isn't.
On Fri, 2006-01-20 at 16:44, Dan Pritts wrote:
On Fri, Jan 20, 2006 at 03:53:33PM -0600, Les Mikesell wrote:
I'd expect to see quite a lot of temp file activity that would
result in changes to unused space on the live system. It would
Yeah, you're right - i think of this as all being
On Fri, Jan 20, 2006 at 04:49:50PM -0600, Les Mikesell wrote:
Even a normal rsync transfer of anything with changes builds
a new copy of the file and replaces the old only when the
new temp copy is complete. Hmmm... I guess that means the
partition image scheme needs disk space for a 2nd
I'm trying to determine if a particular approach might work for offsite backup
copy of BackupPC data store, more-or-less based on a matched pair of hot-swap
SATA LVM disk sets.. and specifically I was wondering if anyone else does
something thus?
ie: (numbers are for illustration only..)
Tim,
My backup pool is much smaller, but what I do is very similar.
I've got 2 400gb sata disks in a Raid1 array. Daily backups go to these
disks where 2 fulls and 5 incremental are saved.
I've also got one removable 400gb disk bay in a 5.25 bay. I use 15
disks and rotate Week 1, Week 2,
14 matches
Mail list logo
