Mailinglist Archive: opensuse (878 mails)

< Previous Next >
Re: [opensuse] Another example of deliberate systemð supporters deliberately sabotaging previously working software...
On 2015-08-03 16:54, Anton Aylward wrote:
On 08/03/2015 10:48 AM, Carlos E. R. wrote:
The name is the same, but the feature is distinctly different.

The purpose is to create a backup of the filesystem into a different
device. It is not a COW (copy on write).

So it really generational backup for potential offlining, perhaps like
disk-to-disk-to-tape.

From memory, and maybe faulty because I have never done it.

I think the procedure is to block changes to the filesystem (this is the
part I'm unsure about), then clone or image the filesystem somewhere
else, as fast as possible, then free up changes again.

If the filesystem would be able to freeze changes, but still accept
them, written somewhere else, delayed, then applied later when the
freeze is removed, that would be wonderful. I don't know if XFS is
capable of this.




Take a look at xfsdump and xfs_copy.

xfsdump creates an image of an XFS filesystem, and does it very fast. It
creates a single target file (an archive). It can be incremental. You do
not need to umount it, I believe (I don't remember for sure; need more
coffe).

xfs_copy instead copies trees of files into another tree. Source and
target must be XFS filesystems. Source should be be umounted, but could
be "frozen" instead. It is similar to using rsync, but runs much faster,
because it takes advantage of knowledge of the metadata structure.



xfs_freeze - suspend access to an XFS filesystem

The manual mentions that is intended for use with lvm or raid with
snapshot support, but I don't see how.

--
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)

< Previous Next >