~看了半天说明，dump和tar好象也没什么特别的区别哦~
===补充说明：dump为备份工具程序，可将目录或整个文件系统备份至指定的设备，或备份成一个大文件
补充说明：tar是用来建立，还原备份文件的工具程序，它可以加入，解开备份文件内的文件。
===
看了半天公社的HELPER~说明上都是备份文件~系统~目录的工具~请问大哥们~他们俩各自的特点是什么啊？ :roll::roll::roll::roll: 嘿嘿 俺还没有机会用呢
ps:从不备份...... :mrgreen: 嘿嘿 俺还没有机会用呢
ps:从不备份...... :mrgreen:
k a o...... 选择tar...
From: Linus Torvalds <[email protected]>
To: Neil Conway <[email protected]>
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc: Kernel Mailing List <[email protected]>
[ linux-kernel added back as a cc ]
On Fri, 27 Apr 2001, Neil Conway wrote:
>
> I'm surprised that dump is deprecated (by you at least ;-)).What to
> use instead for backups on machines that can't umount disks regularly?
Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on "dump" getting backups right is already playing
russian rulette with their backups.It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".
Dump was a stupid program in the first place. Leave it behind.
> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).
Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)data
corruptions of "dump".
However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..
Linus
(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info athttp://vger.kernel.org/majordomo-info.html
Please read the FAQ athttp://www.tux.org/lkml/
......果然有点区别...... E文不好，但是明白以下字眼... :oops::oops::oops:
From: Linus Torvalds <[email protected]>
To: Neil Conway <[email protected]>
Subject: Re: SMP race in ext2 - metadata corruption.
Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc: Kernel Mailing List <[email protected]>
[ linux-kernel added back as a cc ]
On Fri, 27 Apr 2001, Neil Conway wrote:
>
> I'm surprised that dump is deprecated (by you at least ;-)).What to
> use instead for backups on machines that can't umount disks regularly?
Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on "dump" getting backups right is already playing
russian rulette with their backups.It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".
Dump was a stupid program in the first place. Leave it behind.
> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).
Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)data
corruptions of "dump".
However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..
Linus
(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info athttp://vger.kernel.org/majordomo-info.html
Please read the FAQ athttp://www.tux.org/lkml/
页:
[1]