Re: Backup Question

That is true.  Any experiences using any of the recommended
applications with a live system?  Most of our critical apps
are 24x7.  A one time downtime could possibly be worked out
without trouble, but there isn't a lot of support for
repeated downtimes.  That would also be an issue for the
'tar' alternative.  Perhaps the 'dar' scripts would be
useful in that situation, since it can slice up the archive,
therefore consuming less resources I would imagine.  I als
read briefly about the RHN Satellite solution, which would
require our apps to be packaged in a custom RPM for the full
bare metal restore functionality.  Any experience with that
solution?  Thanks again for all the help!

-----Original Message-----
From: nahant-list-bouncesredhat.com
<nahant-list-bouncesredhat.com>
To: Red Hat Enterprise Linux 4 (Nahant) Discussion List
<nahant-listredhat.com>
Sent: Tue Apr 10 19:53:18 2007
Subject: Re: Backup Question

Thatcher, Alan wrote:
> Thanks for all the responses.  One thing I noticed
about each solution is that their main difference from
something like 'tar' or the basic functionality of 'dump'
was that they were designed to easily implement differential
backups.  In our setup we wouldn't necessarily need that, as
we use TSM to do nightly backups of the data we would need
at its most current state (though I do acknowledge that it
can be slow to recover files from tape).  Assuming that we
do not need differential backups every night, tarring up the
system on an NFS mounted filesystem would accomplish the
same thing as the recommended applications would it not?  I
am asking because it would be nice if we didn't have to
install any third party software due to vendor
relations/restrictions.  Thanks....


tar isn't a bare-metal recovery tool. It does not help
recreate 
partitions, format filesystems, install your bootloader and
so on.

Neither does dump do those things.

> 
> 
> -----Original Message-----
> From: nahant-list-bouncesredhat.com
[mailto:nahant-list-bouncesredhat.com] On Behalf Of
John Summerfield
> Sent: Tuesday, April 10, 2007 10:05 AM
> To: Red Hat Enterprise Linux 4 (Nahant) Discussion
List
> Subject: Re: Backup Question
> 
> Brian Long wrote:
> 
>>> While I know that this is probably one of those
argumentative
>>> questions, I was wondering if there is any
consensus on the best way
>>> to perform a backup that would allow for a bare
metal restore 
<snip>


> 
> dar might fit the bill, see dar.sf.net
> 
> 


-- 

Cheers
John

-- spambait
1aaaaaaacoco.merseine.nu  Z1aaaaaaacoco.merseine.nu

Please do not reply off-list

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list

Thatcher, Alan wrote:
> That is true.  Any experiences using any of the
recommended applications with a live system?  Most of our
critical apps are 24x7.  A one time downtime could possibly
be worked out without trouble, but there isn't a lot of
support for repeated downtimes.  That would also be an issue
for the 'tar' alternative.  Perhaps the 'dar' scripts would
be useful in that situation, since it can slice up the
archive, therefore consuming less resources I would imagine.
 I als read briefly about the RHN Satellite solution, which
would require our apps to be packaged in a custom RPM for
the full bare metal restore functionality.  Any experience
with that solution?  Thanks again for all the help!


Backing up open files is a no no*: Unix and Linux allow it,
but the 
result is "undefined."

On a server, that generally means log files and databases.
Forcing log 
rotation helps get those just closed backed up nicely. You
can also 
configure syslogd to log remotely (but not everything uses
syslogd).

Your database software should have its own backup tools;
once you get a 
file out of that, it's just another file.

Note that backing up the Penguin's disks externally does not
work (think 
  of storage devices connected over your LAN: Linux is
likely to have 
data in its buffers not yet on disk when you do your
backup). Same deal 
backing up virtual penguins on their host.


* I have, on the odd occasion, backed up and/or cloned a
running system. 
It worked just fine, but I accepted some data loss (those
logs).

> 
> -----Original Message-----
> From: nahant-list-bouncesredhat.com
<nahant-list-bouncesredhat.com>
> To: Red Hat Enterprise Linux 4 (Nahant) Discussion List
<nahant-listredhat.com>
> Sent: Tue Apr 10 19:53:18 2007
> Subject: Re: Backup Question
> 
> Thatcher, Alan wrote:
>> Thanks for all the responses.  One thing I noticed
about each solution is that their main difference from
something like 'tar' or the basic functionality of 'dump'
was that they were designed to easily implement differential
backups.  In our setup we wouldn't necessarily need that, as
we use TSM to do nightly backups of the data we would need
at its most current state (though I do acknowledge that it
can be slow to recover files from tape).  Assuming that we
do not need differential backups every night, tarring up the
system on an NFS mounted filesystem would accomplish the
same thing as the recommended applications would it not?  I
am asking because it would be nice if we didn't have to
install any third party software due to vendor
relations/restrictions.  Thanks....
> 
> 
> tar isn't a bare-metal recovery tool. It does not help
recreate 
> partitions, format filesystems, install your bootloader
and so on.
> 
> Neither does dump do those things.
> 
>>
>> -----Original Message-----
>> From: nahant-list-bouncesredhat.com
[mailto:nahant-list-bouncesredhat.com] On Behalf Of
John Summerfield
>> Sent: Tuesday, April 10, 2007 10:05 AM
>> To: Red Hat Enterprise Linux 4 (Nahant) Discussion
List
>> Subject: Re: Backup Question
>>
>> Brian Long wrote:
>>
>>>> While I know that this is probably one of
those argumentative
>>>> questions, I was wondering if there is any
consensus on the best way
>>>> to perform a backup that would allow for a
bare metal restore 
> <snip>
> 
> 
>> dar might fit the bill, see dar.sf.net
>>
>>
> 
> 


-- 

Cheers
John

-- spambait
1aaaaaaacoco.merseine.nu  Z1aaaaaaacoco.merseine.nu

Please do not reply off-list

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list

Thanks for the input.  I do realize that I will lose some
data like the
logs, and I know not to try and backup our databases with
other than the
built in tools.  My basic idea is to have a fileset that can
be restored
back onto a server after it has to be rebuilt, and bring it
back to the
same or close to the same state as it was when the backup
was completed.
We use other mechanisms to backup the things that need to be
backed up
on a day to day basis.


-----Original Message-----
From: nahant-list-bouncesredhat.com
[mailto:nahant-list-bouncesredhat.com] On Behalf Of
John Summerfield
Sent: Wednesday, April 11, 2007 7:40 AM
To: Red Hat Enterprise Linux 4 (Nahant) Discussion List
Subject: Re: Backup Question

Thatcher, Alan wrote:
> That is true.  Any experiences using any of the
recommended
applications with a live system?  Most of our critical apps
are 24x7.  A
one time downtime could possibly be worked out without
trouble, but
there isn't a lot of support for repeated downtimes.  That
would also be
an issue for the 'tar' alternative.  Perhaps the 'dar'
scripts would be
useful in that situation, since it can slice up the archive,
therefore
consuming less resources I would imagine.  I als read
briefly about the
RHN Satellite solution, which would require our apps to be
packaged in a
custom RPM for the full bare metal restore functionality. 
Any
experience with that solution?  Thanks again for all the
help!


Backing up open files is a no no*: Unix and Linux allow it,
but the 
result is "undefined."

On a server, that generally means log files and databases.
Forcing log 
rotation helps get those just closed backed up nicely. You
can also 
configure syslogd to log remotely (but not everything uses
syslogd).

Your database software should have its own backup tools;
once you get a 
file out of that, it's just another file.

Note that backing up the Penguin's disks externally does not
work (think

  of storage devices connected over your LAN: Linux is
likely to have 
data in its buffers not yet on disk when you do your
backup). Same deal 
backing up virtual penguins on their host.


* I have, on the odd occasion, backed up and/or cloned a
running system.

It worked just fine, but I accepted some data loss (those
logs).

> 
> -----Original Message-----
> From: nahant-list-bouncesredhat.com
<nahant-list-bouncesredhat.com>
> To: Red Hat Enterprise Linux 4 (Nahant) Discussion
List
<nahant-listredhat.com>
> Sent: Tue Apr 10 19:53:18 2007
> Subject: Re: Backup Question
> 
> Thatcher, Alan wrote:
>> Thanks for all the responses.  One thing I noticed
about each
solution is that their main difference from something like
'tar' or the
basic functionality of 'dump' was that they were designed to
easily
implement differential backups.  In our setup we wouldn't
necessarily
need that, as we use TSM to do nightly backups of the data
we would need
at its most current state (though I do acknowledge that it
can be slow
to recover files from tape).  Assuming that we do not need
differential
backups every night, tarring up the system on an NFS mounted
filesystem
would accomplish the same thing as the recommended
applications would it
not?  I am asking because it would be nice if we didn't have
to install
any third party software due to vendor
relations/restrictions.
Thanks....
> 
> 
> tar isn't a bare-metal recovery tool. It does not help
recreate 
> partitions, format filesystems, install your bootloader
and so on.
> 
> Neither does dump do those things.
> 
>>
>> -----Original Message-----
>> From: nahant-list-bouncesredhat.com
[mailto:nahant-list-bouncesredhat.com] On Behalf Of
John Summerfield
>> Sent: Tuesday, April 10, 2007 10:05 AM
>> To: Red Hat Enterprise Linux 4 (Nahant) Discussion
List
>> Subject: Re: Backup Question
>>
>> Brian Long wrote:
>>
>>>> While I know that this is probably one of
those argumentative
>>>> questions, I was wondering if there is any
consensus on the best
way
>>>> to perform a backup that would allow for a
bare metal restore 
> <snip>
> 
> 
>> dar might fit the bill, see dar.sf.net
>>
>>
> 
> 


-- 

Cheers
John

-- spambait
1aaaaaaacoco.merseine.nu  Z1aaaaaaacoco.merseine.nu

Please do not reply off-list

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list

Russell Harrison wrote:
> Two other solutions that are on my list to evaluate are
Bacula, and
> BackupPC.
> 
> http://www.bacula.org/
> http://backuppc.sour
ceforge.net/

Mine too, but probably you don't want to know I'll be doing
it on Debian.

Speaking of which, Debian's actually made another release.
I'm syncing 
my three RC DVD-sized ISOs as I type)



-- 

Cheers
John

-- spambait
1aaaaaaacoco.merseine.nu  Z1aaaaaaacoco.merseine.nu

Please do not reply off-list

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list