On Wed, Oct 01, 2003 at 11:52:29PM +0900, Nathan Ollerenshaw wrote:
> On Oct 1, 2003, at 10:51 PM, DI Peter Burgstaller wrote:
>
> >That is exactly the beauty of dump. I would have suggested dd for
> >backup/restore but there
> >you have the problem of identical fdisk settings. Dump/restore can
On Wed, 1 Oct 2003 10:05:50 +0200, you wrote:
>we're using a similar setup for some hosts and I have the best results
>so far with dump/restore on ext2/ext3 partitions.
Also using snapshots with dump/restore? Do you have any script which
I could have a look?
>I've even successfully recreated a
Looking through the debian package list I have noticed this a while ago:
afbackup
This is a client-server backup system offering several workstations a
centralized backup to a special backup server. Backing up only one
computer is
easily possible, too. Any streaming device can be used for writin
>> Finally, the 3rd stage: if you're going to save the backup files in an
>> "non-trusty" machine, which kind of container / encryption software
>> would you use? This would need to be easily scriptable, for automatize
>> the backup task.
My idea is to use something like BestCrypt:
http://www.jeti
On Oct 1, 2003, at 10:51 PM, DI Peter Burgstaller wrote:
That is exactly the beauty of dump. I would have suggested dd for
backup/restore but there
you have the problem of identical fdisk settings. Dump/restore can
deal well with bigger partitions.
Definitely use dump.
Its much faster than anyt
finally,
if you dont trust the machine you must encrypt before transfer :-|
lot of time, cpu and disk.
another option could be sign the backup with md5 for example?
this way you can trust the backup content.
i think...
Roman Medina <[EMAIL PROTECTED]> dijo:
> On Wed, 1 Oct 2003 11:42:25 -, y
first of all, sorry G i can't understand your point.
well,
i can tell you about one of my experiences that can explain some points of
your question.
i had a machine with a scsi disk and linux installed, someday i started to
experience some i/o errors on that disk so i have to migrate the instalati
On Wednesday, October 1, 2003, at 3:43 PM, Roman Medina wrote:
On Wed, 1 Oct 2003 11:42:25 -, you wrote:
which is the backup target media?
Hard-disk. The idea is to have another logical partition for backups
and then some scripts to upload/download to any secure site (I could
use rsync over
On Wed, 1 Oct 2003 11:42:25 -, you wrote:
>which is the backup target media?
Hard-disk. The idea is to have another logical partition for backups
and then some scripts to upload/download to any secure site (I could
use rsync over ssh or simply scp). But the uploading is a second step.
Now I'
Alejandro Vartabedian wrote:
the hole file system!
That must be /dev/null !
G
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
what about tar?
it's a good tool, support device files, opened files, etc.
the hole file system!
which is the backup target media?
good luck.
pd: take a look in `man tar`
Roman Medina <[EMAIL PROTECTED]> dijo:
>
> Hi,
>
> I'd like to know which tools&methods do you prefer for backing up a
>
> I might be (and probably am) missing something, but wouldn't rsync (over
> ssh) work?
Does rsync handle device files correctly, hard links, sparse files, etc?
(I'm not trying to troll, I honestly don't know if it handles all of these
things.) I saw an article a while back comparing backup tool
Hi,
we're using a similar setup for some hosts and I have the best results
so far with dump/restore on ext2/ext3 partitions.
I've even successfully recreated a database server with mysql and
postgresql servers running
and using dump as a backup tool.
No problems so far.
- Cheers, Peter
--
Hi,
I might be (and probably am) missing something, but wouldn't rsync (over
ssh) work?
Steve
On Wed, Oct 01, 2003 at 01:00:20AM +0200, Roman Medina wrote:
>
> Hi,
>
> I'd like to know which tools&methods do you prefer for backing up a
> complete Linux install _in a production environment_
Hi,
I'd like to know which tools&methods do you prefer for backing up a
complete Linux install _in a production environment_, i.e., _without
having to shut down the machine or unmount partitions_. The machine
needs to be always alive and it will be remotely administered.
I'd like to hear your
15 matches
Mail list logo
