Mailinglist Archive: opensuse (3280 mails)

< Previous Next >
Re: [opensuse] rsync questions - backups - again !
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Sun, 9 Dec 2007 12:53:26 +0100 (CET)
  • Message-id: <alpine.LSU.0.9999.0712091236100.5956@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



The Saturday 2007-12-08 at 21:25 -0800, Ti Kan wrote:

I find that dd for bare metal backups is dependable. Rsnapshot is fast
and convenient for incremental backups and restores. There are other
solutions that work.

The downside of dd is that you must unmount all filesystems on the
disk to be backed up before doing the copy. Since the dd session
will take time to complete, if the filesystem is mounted and active,
the time between the start and the end of the dd run, changes would have
occurred and you'd end up with an inconsistent filesystem. This is
because the superblock and inode table, etc., would become out of date
and no longer fully reflect the state of the data blocks that gets
eventually backed up. Depending on the amount of activity on the
filesystem, the backup may become corrupt enough to be unusable.
Also, on mission-critical systems, unmounting live filesystems for
backup purposes may not be a feasible option.

One theoretically possible method would be, if you have a raid 1 system, to stop one side, then clone the stopped side to another disk, then reactivate the stopped side.

The copy would be consistent, but of a mounted filesystems: it would have to be fscked before use, after restore.

Then, somebody could do an utility to dd an active partition or disk, recording somewhere what changes were done while the process took place to take them into account on a second pass, faster, and then a third, etc, till the copy would be fully consistent.

Another theoretical possibility would be the contrary: the system would freeze the source partition sourcing the dd (call it dump), recording somewhere else the changes done by other programs; ie, the changes would not be written on the intended partition, but on another "recent changes" partition. When the dump was complete, the partition would be reactivated the "recent changes" and be applied again.

Scary, eh? I have seen some thing similar, though...


Then, if you are using xfs, these utilities can be used, without umounting:

xfs_freeze -f
xfs_copy
xfs_freeze -u

xfsdump is missing, but mentioned.


- -- Cheers,
Carlos E. R.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFHW9c3tTMYHG2NR9URAidsAJ4gMLkk78hpsXONxu6JJf2fu8NeVgCghhvV
f1NPlbvyHa3VqyM6PXXD2ro=
=yvG0
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
References