On Sunday 10 June 2012 23:14:57 Ronald F. Guilmette wrote:
> Well, nevermind about that. I get the general idea, i.e. that dumping
> at level N causes dumping of everything that has changed since the last
> dump at level N-1.
A point to be aware of is that if you restore from a full backup follo
On Monday 11 June 2012 00:03:59 Daniel Feenberg wrote:
> It does occur to me that /etc is not a felicitous place to keep this
> information, but given the desirability of dumping filesystems in read
> only state, placing the dump dates in the filesystem itself isn't
> feasible.
Dumping with the -
On 10/06/2012 23:14, Ronald F. Guilmette wrote:
> Well, nevermind about that. I get the general idea, i.e. that dumping
> at level N causes dumping of everything that has changed since the last
> dump at level N-1.
Not quite. A dump at level N includes everything that changed since the
most rece
On Sun, 10 Jun 2012, Robert Huff wrote:
Ronald F. Guilmette writes:
Warren? Just a couple more quick questions. You recommend:
>> dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore -ruf -)
I'm real curious about you suggestions for the -C and -b values.
I have what amounts to
Ronald F. Guilmette writes:
> Warren? Just a couple more quick questions. You recommend:
>
> >> dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore -ruf -)
>
> I'm real curious about you suggestions for the -C and -b values.
>
> I have what amounts to a personal workstation.
"Ronald F. Guilmette" wrote:
> Warren Block wrote:
> >On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
>
> >> ... I mean if I do the pipeline from dump
> >> to restore as you have shown in your examples in your "Copying Filesystems"
> >> section, then what must I do in order prevent dump from du
On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
What I don't understand (and what I wish someone would enlighten me about)
is just this: It would seem that in order to implement these dump levels,
dump must be keeping a record somewhere, for each file in the filesystem,
of the level at whic
On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
In message ,
Warren Block wrote:
On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
1) In your example under the heading "Copying Filesystems", the second
shell command line shown is:
dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore
Warren? Just a couple more quick questions. You recommend:
>> dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore -ruf -)
I'm real curious about you suggestions for the -C and -b values.
I have what amounts to a personal workstation. Yea, OK, it is running
mail, web, and FTP servers
In message ,
Warren Block wrote:
>On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
>> 1) In your example under the heading "Copying Filesystems", the second
>> shell command line shown is:
>>
>> dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore -ruf -)
>>
>> Is that correct? Shouldn'
On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
(I got the Wrong Impression, I think, because I have read assertions like
"...dump backs up at the filesystem block level...". What does that mean
exactly? Use of the term "block level" in this context makes me think of
something operating along
In message , you wrote:
>On Sat, 9 Jun 2012, Ronald F. Guilmette wrote:
>
>>
>> Also, I don't like backups taking longer than absolutely necessary, and
>> this is why I am specifically _not_ attracted to either the dd solution
>> or to dump/restore, because as I understand it, with either of thes
> From owner-freebsd-questi...@freebsd.org Sat Jun 9 21:33:57 2012
> To: Arthur Chance
> Date: Sat, 09 Jun 2012 19:30:53 -0700
> From: "Ronald F. Guilmette"
> Cc: freebsd-questions@freebsd.org
> Subject: Re: Making a bootable backup (hard)disk... how?
>
>
&
On Sunday 10 June 2012 03:30:53 Ronald F. Guilmette wrote:
> I don't care to take own my system to make backups... and don't believe
> that I should have to do so, and thus, this is one of the reasons why I
> would prefer to use something like cpio.
>
> Also, I don't like backups taking longer tha
Hello.
2012/06/09 19:30:53 -0700 "Ronald F. Guilmette" => To
Arthur Chance :
RFG> Thank you Arthur, and yes, trying to back up a partition that's currently
RFG> mounted r/w using dd will almost certainly not produce the desired results.
You can make snapshot to back up rw-mounted volume with d
On Sat, 9 Jun 2012, Ronald F. Guilmette wrote:
Also, I don't like backups taking longer than absolutely necessary, and
this is why I am specifically _not_ attracted to either the dd solution
or to dump/restore, because as I understand it, with either of these methods
you end up copying perhaps
In message <4fd38b9a.4010...@qeng-ho.org>,
Arthur Chance wrote:
>There's a BFI (brute force and ignorance) way of doing it in the base
>system - dd. Provided your system disk is quiescent (ideally when
>running from a live CD or all partitions mounted read-only, otherwise
>pray to the deity o
On 06/09/12 00:58, Warren Block wrote:
On Fri, 8 Jun 2012, Robert Huff wrote:
Ronald F. Guilmette writes:
I got a lot of disks here, so that part is not a problem. I just
need to make sure that I'm gonna do this the Right Way[tm].
(I've already been making my own ham-fisted disk-to-disk back
On Fri, Jun 8, 2012 at 4:58 PM, Warren Block wrote:
> On Fri, 8 Jun 2012, Robert Huff wrote:
>
>
>> Ronald F. Guilmette writes:
>>
>> I got a lot of disks here, so that part is not a problem. I just
>>> need to make sure that I'm gonna do this the Right Way[tm].
>>> (I've already been making
On Fri, 8 Jun 2012, Robert Huff wrote:
Ronald F. Guilmette writes:
I got a lot of disks here, so that part is not a problem. I just
need to make sure that I'm gonna do this the Right Way[tm].
(I've already been making my own ham-fisted disk-to-disk backups
in the past, but I'm sure that
Ronald F. Guilmette writes:
> I got a lot of disks here, so that part is not a problem. I just
> need to make sure that I'm gonna do this the Right Way[tm].
> (I've already been making my own ham-fisted disk-to-disk backups
> in the past, but I'm sure that the way I have been doing that is
>
I've been lucky. Over about the past 20 years I've never had a hard
disk go bad on me. (Knock on wood.) Of course I _do_ only buy the
better quality ones (with the 5 year warranties), and I'm sure that
has helped. Still, one never knows, and it is best to be prepared.
Primarily however, I am m
22 matches
Mail list logo
