You are not logged in.
If you copy a whole file system of a running system while data is being written to it will that result in an inconsistent snapshot? By inconsistent I mean that two files, or the first last part of a file are from different points in time? Does this differ per filesystem-type or backup method?
Last edited by rwd (2009-04-12 08:45:55)
Offline
i think copying a running system is a bigger problem than that. there's a lot of files in /dev and /proc that you really don't want to copy/paste from one running system to another. if you want to move / do it form a live cd. if you're scripting a backup, then just backup /etc /usr /var and /home then restore those to the new system, you won't know the difference.
//github/
Offline
I remember with databases you can't generally just copy the database files of a running database and expect to restore it, /usr/ and /etc/ may contain static files, but some apps store things in sqlite databases in /home/ for example. My question was also a bit out of curiosity: do some filesystems have the ability to let you select an exact snapshot in time, just like a 'select' query in a rdms, (without having to access it from something like a livecd)?
Last edited by rwd (2009-04-10 21:23:54)
Offline
do some filesystems have the ability to let you select an exact snapshot in time, just like a 'select' query in a rdms, (without having to access it from something like a livecd)?
nilfs
by the way you can copy the filesystem while it is running no problem. of course when a program has stored an inconsistent state of a file to the disk then it's its problem, but IMHO no reasonable (for instance journaling) filesystem will serve you an inconsistent state of a file, even when written to.
of course when taking backups you shouldn't backup /proc and /sys (dynamically created by the kernel) and /dev (dynamically created by udev and some static parts by the initscripts when booting).
Offline
bender02 is right. I daily backup my running system to another partition.
I do boot from that partition mainly for testing purposes, like testing other kernels that could break my
running system.
mount /dev/sdb2 /backup
rsync -av --delete --delete-excluded --exclude="/proc/**" --exclude="/sys/**"
--exclude="/dev/**" --exclude="/backup/" / /backup
Mektub
Follow me on twitter: https://twitter.com/johnbina
Offline
bender02 is right. I daily backup my running system to another partition.
I do boot from that partition mainly for testing purposes, like testing other kernels that could break my
running system.mount /dev/sdb2 /backup rsync -av --delete --delete-excluded --exclude="/proc/**" --exclude="/sys/**" --exclude="/dev/**" --exclude="/backup/" / /backup
Mektub
I am just experimenting with this sort of rsync backup. Just one thing I do not readily understand, why do you exclude contents: "/proc**", etc. Would it not be more appropriate to exclude the whole directory, using instead:
mount /dev/sdb2 /backup
rsync -av --delete --delete-excluded --exclude="/proc/" --exclude="/sys/"
--exclude="/dev/" --exclude="/backup/" / /backup
That way it doesn't even attempt to backup any of those folders.
Last edited by bernarcher (2009-04-11 11:02:22)
To know or not to know ...
... the questions remain forever.
Offline
bernacher,
I am just experimenting with this sort of rsync backup. Just one thing I do not readily understand, why do you exclude contents: "/proc**", etc. Would it not be more appropriate to exclude the whole directory, using instead:
"/proc/**" creates the empty /proc/ in the backup, and it is needed when booting.
"/proc/' will not create the directory.
Mektub
Follow me on twitter: https://twitter.com/johnbina
Offline
"/proc/**" creates the empty /proc/ in the backup, and it is needed when booting.
"/proc/' will not create the directory.
Mektub
Ah, right! I did not think of that. Only noticed that rsync tried to copy the /proc, etc. contents as well which I definitely did not want.
Still studying man rsync. It appears somewhat overwhelming at first sight.
Thanks for the info.
To know or not to know ...
... the questions remain forever.
Offline