Jeffrey J. Kosowsky wrote:
> I agree with your need but good luck since there is a vociferous group
> of contributors here who think the solution is always ZFS or general
> block copy. They can't seem to understand that not only is there a
> broad base of users who would like a file-level backup a
>
>
> You seem to have the illusion that sql can magically avoid the head motions
> that
> make backuppc slow while still getting the same things on the same disks.
> While
> it is possible to tune most sql servers to put different tables on
> different
> drives, there's a fair chance that in a de
/// > > But a program should not be dependent on volume management. Volume
> > > management is a general tool that can be helpful but should not be
> > > required.
> >
> / > you think that expanding an SQL database would be different?
>
> It would be *very* different since you can easily copy
Jim Leonard wrote at about 22:18:07 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > > I read the docs before setting it up and it was very obvious to me that
> > > planning was required. Then again, I've been doing this for a while.
> > > But it *was* in the document
Jim Leonard wrote at about 22:07:36 -0500 on Tuesday, September 1, 2009:
> > > I have already mentioned that your filesystem's "dump" utility
> > > works perfectly well for copying your filesystem, hardlinks and all,
> > > ACLs and all, to another filesystem/file/tape/whatever. I think you
Jim Leonard wrote:
> Peter Walter wrote:
>
>>> Why can't you use ext3 dump? (http://sourceforge.net/projects/dump/)
>>>
>>>
>> I might consider it, if I could find the manual so I could read up on
>> how to use it. Could you point me to a link?
>>
>
> Was that a joke? The link
Jeffrey J. Kosowsky wrote:
> > I read the docs before setting it up and it was very obvious to me that
> > planning was required. Then again, I've been doing this for a while.
> > But it *was* in the documentation, if not in-your-face explicit.
>
> OK - can you show me where in the documenta
Jeffrey J. Kosowsky wrote:
> > Now it is you who is using the straw-man argument, because backuppc
> > *can* easily be backed up at the file level. You just don't like how
> > long it takes and/or that it doesn't work quickly with your favorite
> > utility.
>
> Really - then why do people
Peter Walter wrote:
>> Why can't you use ext3 dump? (http://sourceforge.net/projects/dump/)
>>
> I might consider it, if I could find the manual so I could read up on
> how to use it. Could you point me to a link?
Was that a joke? The link was right after the question mark in my
original se
Peter Walter wrote:
> What I don't understand is why such a great backup system such as
> backuppc cannot reasonably be used to backup itself - it seems to me
> that since backuppc "knows" it's own architecture, a way could be found
> to do it efficiently.
Actually, backuppc doesn't know that
Les Mikesell wrote at about 13:42:16 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > Les Mikesell wrote at about 12:15:34 -0500 on Tuesday, September 1, 2009:
> > > Jeffrey J. Kosowsky wrote:
> > > > > 2) you lose power/crash while expiring
> > > > This would just mea
Jeffrey J. Kosowsky wrote:
> Les Mikesell wrote at about 12:15:34 -0500 on Tuesday, September 1, 2009:
> > Jeffrey J. Kosowsky wrote:
> > > > 2) you lose power/crash while expiring
> > > This would just mean that expiry not completed meaning that some
> > > expired files not deleted. Same prob
Peter Walter wrote at about 13:27:38 -0400 on Tuesday, September 1, 2009:
> Les Mikesell wrote:
> > Peter Walter wrote:
> >
> >> Jim Leonard wrote:
> >>
> >>> Peter Walter wrote:
> >>>
> >>>
> I have access to "cloud storage" I would like to take
> advantage o
Les Mikesell wrote at about 12:15:34 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > > 2) you lose power/crash while expiring
> > This would just mean that expiry not completed meaning that some
> > expired files not deleted. Same problem occurs if power/crash during
> >
Les Mikesell wrote:
> Peter Walter wrote:
>
>> Jim Leonard wrote:
>>
>>> Peter Walter wrote:
>>>
>>>
I have access to "cloud storage" I would like to take
advantage of, but can't because of the hardlink issue. My (klugey)
solution at present is to use a backuppc s
Jeffrey J. Kosowsky wrote:
>
> > > Name the top 10 that worry you most so that I can get a feeling for
> > > how hard they are to solve. Again, I can't address a generic fear.
> >
> > 1) you've run out of disk space, corrupting the database
> Would cause similar problem with current implement
Holger Parplies wrote:
> Hi,
>
> Jim Leonard wrote on 2009-08-31 23:55:10 -0500 [Re: [BackupPC-users] Problems
> with hardlink-based backups...]:
>> [...]
>> Why can't you use ext3 dump? (http://sourceforge.net/projects/dump/)
>
> I don't know the detai
Jim Leonard wrote:
> Peter Walter wrote:
>
>>> What is the problem with your cloud storage such that you can't use it
>>> to make a backup of BackupPC? What cloud storage do you have access to,
>>> and what operating system and filesystem are you using to run BackupPC?
>>>
>>>
>> I
Hi,
Jeffrey J. Kosowsky wrote on 2009-09-01 01:18:28 -0400 [Re: [BackupPC-users]
Problems with hardlink-based backups...]:
> Michael Stowe wrote at about 23:15:15 -0500 on Monday, August 31, 2009:
> >
> > > I don't see the issue here.
> > > - New files are
Les Mikesell wrote at about 01:40:27 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > > > > > I guess I can't answer your question without knowing what use
> > cases
> > > > > > you are worried about.
> > > > >
> > > > > All of them.
> >
> > Name the top 10 t
Hi,
Jim Leonard wrote on 2009-08-31 23:55:10 -0500 [Re: [BackupPC-users] Problems
with hardlink-based backups...]:
> [...]
> Why can't you use ext3 dump? (http://sourceforge.net/projects/dump/)
I don't know the details of the dump program you are referring to, but those I
have
> As I mentioned this is not (well) documented in the BackupPC
> documentation and continues to trip up new and not-so-new users
> alike. Also, there are use cases where you can't have a single FS for
> BackupPC (though Michael Stowe has decided to call them "fringe")
I prefer not to be misconstr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey J. Kosowsky wrote:
> Adam Goryachev wrote at about 14:14:49 +1000 on Tuesday, September 1, 2009:
> > Jeffrey J. Kosowsky wrote:
> > > Jim Leonard wrote at about 20:20:59 -0500 on Monday, August 31, 2009:
> > > > Jeffrey J. Kosowsky wrote:
>
On Mon, Aug 31, 2009 at 05:14:20PM -0400, Peter Walter wrote:
> I am therefore restricted to copying the primary backup server itself.
> The intent is not to be able to recover the targets directly - the aim
> is to recover the primary backup server, and, from there, recover the
> targets. If
Jeffrey J. Kosowsky wrote:
> > > > > I guess I can't answer your question without knowing what use cases
> > > > > you are worried about.
> > > >
> > > > All of them.
>
> Name the top 10 that worry you most so that I can get a feeling for
> how hard they are to solve. Again, I can't addre
Jeffrey J. Kosowsky wrote:
> Les Mikesell wrote at about 00:51:43 -0500 on Tuesday, September 1, 2009:
> > Jeffrey J. Kosowsky wrote:
> > > > > > Yes, except for people using a consumer NAS.
> > > > > Which is why you want to *backup* your backup database which is one
> of
> > > > > the wh
Les Mikesell wrote at about 00:51:43 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > > > > Yes, except for people using a consumer NAS.
> > > > Which is why you want to *backup* your backup database which is one of
> > > > the whole points of this whole thread.
> > >
Jim Leonard wrote at about 00:17:04 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > > BackupPC isn't "dependent" on volume management more than any other
> > > program. Volume management is simply one way to get around the
> > > limitations of storing more data than
Jeffrey J. Kosowsky wrote:
> > > > Yes, except for people using a consumer NAS.
> > > Which is why you want to *backup* your backup database which is one of
> > > the whole points of this whole thread.
> >
> > Yes, but at that level you use the techniques the device offers. Won't
> the NAS
Jim Leonard wrote at about 00:05:19 -0500 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > In contrast, the normal usage of hard links uses a
> > single inode to represent the same file albeit differing only in name.
>
> There is nothing abnormal about the use of hard links her
Jim Leonard wrote at about 23:53:13 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> > it seems that many
> > people (myself included) initially set up their BackupPC topdir on a
> > filesystem containing mixed data and without the advantage of things
> > like LVM or ZFS since
Les Mikesell wrote at about 21:13:38 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> >
> > > How's that? You have to install some unix-like OS distribution.
> > > There's not a huge difference.
> >
> > Here is the difference:
> > 1. SQL database
> > 1. Most Linux dis
Peter Walter wrote:
> Jim Leonard wrote:
>> Peter Walter wrote:
>>
>>> I have access to "cloud storage" I would like to take
>>> advantage of, but can't because of the hardlink issue. My (klugey)
>>> solution at present is to use a backuppc server to backup the backuppc
>>> server, but even i
Michael Stowe wrote at about 23:15:15 -0500 on Monday, August 31, 2009:
>
> > I don't see the issue here.
> > - New files are created only when a new file is added to the
> > pool. Since this happens coincident with the need for a new database
> > entry, these two operations can be synchr
Jeffrey J. Kosowsky wrote:
> > BackupPC isn't "dependent" on volume management more than any other
> > program. Volume management is simply one way to get around the
> > limitations of storing more data than a single device will allow. Do
> > you think that expanding an SQL database would
Jeffrey J. Kosowsky wrote:
> In contrast, the normal usage of hard links uses a
> single inode to represent the same file albeit differing only in name.
There is nothing abnormal about the use of hard links here. What
operating environment are you basing your definition of "normal" on?
This is
Adam Goryachev wrote at about 14:14:49 +1000 on Tuesday, September 1, 2009:
> Jeffrey J. Kosowsky wrote:
> > Jim Leonard wrote at about 20:20:59 -0500 on Monday, August 31, 2009:
> > > Jeffrey J. Kosowsky wrote:
> > > > Is it self-evident that a BackupPC tree is difficult to
> > > > copy/mo
Peter Walter wrote:
>> What is the problem with your cloud storage such that you can't use it
>> to make a backup of BackupPC? What cloud storage do you have access to,
>> and what operating system and filesystem are you using to run BackupPC?
>>
> I have not (yet) come across a cloud storage
Michael Stowe wrote at about 22:53:02 -0500 on Monday, August 31, 2009:
>
> Three small points:
>
> 1) LVM is de rigeur for any substantial Linux-based filesystem
Not all Linux installations support LVM - oh yeah, I forgot, you
consider a consumer-NAS to be a "fringe" case.
> 2) You don't
Michael Stowe wrote at about 22:53:02 -0500 on Monday, August 31, 2009:
>
> Three small points:
>
> 1) LVM is de rigeur for any substantial Linux-based filesystem
Not all Linux installations support LVM - oh yeah, I forgot, you
consider a consumer-NAS to be a "fringe" case.
> 2) You don't
Jeffrey J. Kosowsky wrote:
> it seems that many
> people (myself included) initially set up their BackupPC topdir on a
> filesystem containing mixed data and without the advantage of things
> like LVM or ZFS since they don't realize in advance how hard it is to
> copy/move/resize the topdir area du
Michael Stowe wrote at about 22:41:06 -0500 on Monday, August 31, 2009:
>
> > Then I would suggest you haven't seen enough software. Backup systems
> > are not trivial systems, and it should be implied that you would never
> > set them up without consulting their operation and requirements.
Jim Leonard wrote at about 17:17:24 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> > But a program should not be dependent on volume management. Volume
> > management is a general tool that can be helpful but should not be
> > required.
>
> BackupPC isn't "dependent" on vo
Jim Leonard wrote at about 16:55:04 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> > The kludge is not the use per-se of hard links
> > to store the file data but the resulting collapsing of multiple
> > version of the same file to a single inode that correspond to
> > differ
Jim Leonard wrote:
> Peter Walter wrote:
>
>> I have access to "cloud storage" I would like to take
>> advantage of, but can't because of the hardlink issue. My (klugey)
>> solution at present is to use a backuppc server to backup the backuppc
>> server, but even incrementals take days to run
Jeffrey J. Kosowsky wrote:
>
> > How's that? You have to install some unix-like OS distribution.
> > There's not a huge difference.
>
> Here is the difference:
> 1. SQL database
> 1. Most Linux distributions already include a version of sql in the
> base install
> If not "yum install
Jim Leonard wrote:
> Peter Walter wrote:
>
>> Perhaps - but a very close second. Backuppc is very stable and robust.
>> But, disasters do happen. I have had my grits saved at least twice by
>> having a remote backup of the backup server (remember Katrina and New
>> Orleans?) and I am very ne
Hi,
Marty wrote on 2009-08-31 19:58:58 -0400 [Re: [BackupPC-users] Problems with
hardlink-based backups...]:
> Peter Walter wrote:
> > [...]
> > If I had a method of simply backing up the changed files on the
> > backup server, and a method of dumping the hardlinks in su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey J. Kosowsky wrote:
> Jim Leonard wrote at about 20:20:59 -0500 on Monday, August 31, 2009:
> > Jeffrey J. Kosowsky wrote:
> > > Is it self-evident that a BackupPC tree is difficult to
> > > copy/move/resize if not on a dedicated filesystem?
> I don't see the issue here.
> - New files are created only when a new file is added to the
> pool. Since this happens coincident with the need for a new database
> entry, these two operations can be synchronized
Unless there's a database problem. Or the executable crashes. Or a
programmin
Three small points:
1) LVM is de rigeur for any substantial Linux-based filesystem
2) You don't have to move it anywhere, you can just start a new repository
elsewhere
3) My filesystem isn't dedicated by any means, and I can't think of a good
reason to do so
> Jim Leonard wrote at about 20:20:59
Les Mikesell wrote at about 15:23:41 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> > More generally, we would need to consider two things:
> > 1. What are the normal ways in which the two could get out of synch
> >and then address each of those cases
>
> Start with th
Holger Parplies wrote:
> Hi,
>
> Marty wrote on 2009-08-31 19:58:58 -0400 [Re: [BackupPC-users] Problems with
> hardlink-based backups...]:
>> Peter Walter wrote:
>> > [...]
>> > If I had a method of simply backing up the changed files on the
>> &g
Jim Leonard wrote at about 20:20:59 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> > Is it self-evident that a BackupPC tree is difficult to
> > copy/move/resize if not on a dedicated filesystem?
>
> What is a "dedicated filesystem"? How does it differ from any other
> f
> Then I would suggest you haven't seen enough software. Backup systems
> are not trivial systems, and it should be implied that you would never
> set them up without consulting their operation and requirements.
I have it on good authority that if you post to a list copiously enough
for a long e
Holger Parplies wrote at about 02:05:28 +0200 on Tuesday, September 1, 2009:
> Hi,
>
> Jeffrey J. Kosowsky wrote on 2009-08-31 18:15:07 -0400 [Re: [BackupPC-users]
> Problems with hardlink-based backups...]:
> > Les Mikesell wrote at about 15:23:41 -0500 on Monda
Peter Walter wrote:
>
> Perhaps - but a very close second. Backuppc is very stable and robust.
> But, disasters do happen. I have had my grits saved at least twice by
> having a remote backup of the backup server (remember Katrina and New
> Orleans?) and I am very nervous about using a backup
Jeffrey J. Kosowsky wrote:
> The kludge is not the use per-se of hard links
> to store the file data but the resulting collapsing of multiple
> version of the same file to a single inode that correspond to
> different inodes and file attributes in the source data.
You do not have a clear understa
Peter Walter wrote:
> I have access to "cloud storage" I would like to take
> advantage of, but can't because of the hardlink issue. My (klugey)
> solution at present is to use a backuppc server to backup the backuppc
> server, but even incrementals take days to run.
What is the problem with yo
Jeffrey J. Kosowsky wrote:
> But a program should not be dependent on volume management. Volume
> management is a general tool that can be helpful but should not be
> required.
BackupPC isn't "dependent" on volume management more than any other
program. Volume management is simply one way to ge
Les Mikesell wrote at about 18:24:20 -0500 on Monday, August 31, 2009:
> How's that? You have to install some unix-like OS distribution.
> There's not a huge difference.
Here is the difference:
1. SQL database
1. Most Linux distributions already include a version of sql in the
base insta
Jeffrey J. Kosowsky wrote:
> Is it self-evident that a BackupPC tree is difficult to
> copy/move/resize if not on a dedicated filesystem?
What is a "dedicated filesystem"? How does it differ from any other
filesystem?
--
Jim Leonard (trix...@oldskool.org)http://www.oldskool.org/
He
> > Just because a word processor has tables doesn't mean you shouldn't be
> > using a spreadsheet.
>
> huh? your statement is not even logically parallel let only
> comprehensible. Do you just like to argue for arguments sake or only
> to avoid admitting you were wrong?
Then I'll explain: you
Holger Parplies wrote at about 01:25:40 +0200 on Tuesday, September 1, 2009:
*snipped all the irrelevant and patronizing comments*
> How do you ensure consistency between database content and file
> system content? Please answer that, for once!
How do you ensure consistency between the pool an
I wrote:
> issue, and I have used it for my small file pool (220MB), which syncs in
Sorry, I meant 220GB.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design
Hi,
Jeffrey J. Kosowsky wrote on 2009-08-31 18:15:07 -0400 [Re: [BackupPC-users]
Problems with hardlink-based backups...]:
> Les Mikesell wrote at about 15:23:41 -0500 on Monday, August 31, 2009:
> > Jeffrey J. Kosowsky wrote:
> > > [...]
> > > I guess I can
Peter Walter wrote:
> Terabyte image copies between servers are not feasible with the WAN
> bandwidth I have available. The second backup server does not (and
> cannot) backup the original targets directly - the second backup server
> may only access the primary backup servers remotely, not th
Michael Stowe wrote at about 18:02:44 -0500 on Monday, August 31, 2009:
>
> > Yes I know you run Open Solaris. However, 99.99% of computer users
> > don't so we don't have access to zfs. On the other hand free sql
> > database applications are available on just about any OS. Why is so
> > har
Hi Jeffrey, hi all,
Jeffrey J. Kosowsky wrote on 2009-08-31 18:41:18 -0400 [Re: [BackupPC-users]
Problems with hardlink-based backups...]:
> [...]
> This is getting ridiculous. Who cares?
I do (even if I'm quoting out of context).
Frankly, this discussion has been ridiculous fro
Jeffrey J. Kosowsky wrote:
> >
> > Is it? I think rsync or tar would handle them rather easily and toss
> > them on about any media without regard to having a matching database
> > application running.
>
> It would take a lot longer since it would be implicitly doing a "find"
> down a v
> Yes I know you run Open Solaris. However, 99.99% of computer users
> don't so we don't have access to zfs. On the other hand free sql
> database applications are available on just about any OS. Why is so
> hard to understand that Open Solaris is not just an option for the
> average user. It is a
Michael Stowe wrote:
Another disadvantage of the current approach is that it is difficult
to perform queries such as:
"How many copies of file xyz do I have?"
"Return the latest version of file xyz across the following hosts?"
(and infinite variations and extensions of the above)
Does this
Michael Stowe wrote at about 17:48:09 -0500 on Monday, August 31, 2009:
>
> > Another disadvantage of the current approach is that it is difficult
> > to perform queries such as:
> > "How many copies of file xyz do I have?"
> > "Return the latest version of file xyz across the following hosts
Michael Stowe wrote at about 17:27:33 -0500 on Monday, August 31, 2009:
>
> > OK. Then we have different use cases. For example. I like to use the fuser
> > implementation to look for old files or old versions of files.
>
> Would you mind elaborating?
Someone wrote a cute little fuser files
Les Mikesell wrote at about 17:22:27 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> >
> > > > I have seen problems where the attrib files are not synchronized with
> > > > the backups or when the pc tree is broken. In fact, that is the reason
> > > > I wrote several of my
> Another disadvantage of the current approach is that it is difficult
> to perform queries such as:
> "How many copies of file xyz do I have?"
> "Return the latest version of file xyz across the following hosts?"
> (and infinite variations and extensions of the above)
Does this really come up mu
Michael Stowe wrote at about 17:15:47 -0500 on Monday, August 31, 2009:
>
> > Words like "fringe", "shenanigans" are pejorative - no matter how you
> > couch it. My response was hardly ad-hominem, but rather suggesting if
> > you went based on actual contributions to the BackupPC community the
> OK. Then we have different use cases. For example. I like to use the fuser
> implementation to look for old files or old versions of files.
Would you mind elaborating?
--
Let Crystal Reports handle the reporting - Free
Jeffrey J. Kosowsky wrote:
>
> > > I have seen problems where the attrib files are not synchronized with
> > > the backups or when the pc tree is broken. In fact, that is the reason
> > > I wrote several of my routines to identify and fix such problems. Now
> > > true, the cause is typically du
> Words like "fringe", "shenanigans" are pejorative - no matter how you
> couch it. My response was hardly ad-hominem, but rather suggesting if
> you went based on actual contributions to the BackupPC community then
> you would be way more fringe than me -- that's all.
There's a big difference be
Les Mikesell wrote at about 15:23:41 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> > >
> > > > I see lots of advantage in keeping the database portion relatively
> > > > small, fast, replicable, and moveable. Then you can keep and
> > > > distribute the files themselves
Les Mikesell wrote at about 16:36:37 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> >
> > I have seen problems where the attrib files are not synchronized with
> > the backups or when the pc tree is broken. In fact, that is the reason
> > I wrote several of my routines to id
Michael Stowe wrote at about 16:29:40 -0500 on Monday, August 31, 2009:
> > Michael Stowe wrote at about 15:48:17 -0500 on Monday, August 31, 2009:
> > >
> > > > > In other words, I'd suggest that working around the limitations of
> > your
> > > > > consumer-grade NAS is probably beyond t
> Michael Stowe wrote at about 15:29:42 -0500 on Monday, August 31, 2009:
> >
> > > Use of hard links to reduce
> > > disk usage dates back to the inception of hard links. It's not a
kludge, its an established feature of unix based filesystems.
> >
> > It's also an established feature of Wind
Jeffrey J. Kosowsky wrote:
>
> I have seen problems where the attrib files are not synchronized with
> the backups or when the pc tree is broken. In fact, that is the reason
> I wrote several of my routines to identify and fix such problems. Now
> true, the cause is typically due to crashes or dis
> Michael Stowe wrote at about 15:48:17 -0500 on Monday, August 31, 2009:
> >
> > > > In other words, I'd suggest that working around the limitations of
> your
> > > > consumer-grade NAS is probably beyond the scope of any backup
> system.
> > >
> > > How nice of you. And please remind me of
Michael Stowe wrote at about 15:29:42 -0500 on Monday, August 31, 2009:
>
> > Use of hard links to reduce
> > disk usage dates back to the inception of hard links. It's not a
> > kludge, its an established feature of unix based filesystems.
>
> It's also an established feature of Windows'
Les Mikesell wrote:
> Peter Walter wrote:
>
>> Les Mikesell wrote:
>>
>>> Peter Walter wrote:
>>>
>>>
For me, the matter could be resolved if a
way was found to at least backup a backuppc server in a reasonable
fashion without requiring particular filesystems and
Les Mikesell wrote at about 15:56:16 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> >
> > No one said "education". I said warn users of the advisability of
> > using a dedicated filesystem that can easily be
> > copied/resized/moved. Because most people don't recognize the p
Michael Stowe wrote at about 15:48:17 -0500 on Monday, August 31, 2009:
>
> > > In other words, I'd suggest that working around the limitations of your
> > > consumer-grade NAS is probably beyond the scope of any backup system.
> >
> > How nice of you. And please remind me of all the code y
Hi all,
On Mon, Aug 31, 2009 at 04:32:14PM -0400, Jeffrey J. Kosowsky wrote:
> In a very real sense, the current implementation already uses an
> artificial database structure - albeit it a slow, prorprietary,
> non-extensible, non-optimizable version. To wit, the attrib files
> present in each a
Jeffrey J. Kosowsky wrote:
>
> No one said "education". I said warn users of the advisability of
> using a dedicated filesystem that can easily be
> copied/resized/moved. Because most people don't recognize the problem
> of copying/moving/resizing their BackupPC database until they have
> been usi
Jon Craig wrote at about 16:23:44 -0400 on Monday, August 31, 2009:
> On Mon, Aug 31, 2009 at 3:23 PM, Jeffrey J.
> Kosowsky wrote:
>
> >
> > I really fail to understand the dogged resistance to finding a viable
> > solution to a well-known and repeated issue with BackupPC that does
> > not
> > In other words, I'd suggest that working around the limitations of
your consumer-grade NAS is probably beyond the scope of any backup
system.
>
> How nice of you. And please remind me of all the code you have
> contributed to BackupPC and to this user group...
I don't think a discussion of sc
Les Mikesell wrote at about 15:08:24 -0500 on Monday, August 31, 2009:
> Jeffrey J. Kosowsky wrote:
> >
> > This still is not a solution for all of us. First, I store the backups
> > on a consumer-level NAS device that does not easily facilitate adding
> > partitions without additional hackin
Jon Craig wrote:
> Lastly, we wouldn't be having a discusion about replicating the
> backuppc server if backuppc wasn't as stable and robust as it is.
> BackupPC must first and foremost be a reliable and trustworthy
> repository of backup data. It having the ability to replicate itself
> for "DR
Michael Stowe wrote at about 14:56:38 -0500 on Monday, August 31, 2009:
>
> > I don't see why everything needs to worship at the alter of atomic
> > operations. There are other ways to ensure that things don't go wrong.
>
> There probably isn't, frankly. And is there a better way of ensurin
> Use of hard links to reduce
> disk usage dates back to the inception of hard links. It's not a
> kludge, its an established feature of unix based filesystems.
It's also an established feature of Windows' filesystem NTFS, for the record.
Michael Stowe wrote at about 14:41:21 -0500 on Monday, August 31, 2009:
>
> > This still is not a solution for all of us. First, I store the backups
> > on a consumer-level NAS device that does not easily facilitate adding
> > partitions without additional hacking and risks to data integrity.
Peter Walter wrote:
> Les Mikesell wrote:
>> Peter Walter wrote:
>>
>>> For me, the matter could be resolved if a
>>> way was found to at least backup a backuppc server in a reasonable
>>> fashion without requiring particular filesystems and utilities such as
>>> zfs send/receive.
>>>
>>
1 - 100 of 148 matches
Mail list logo
