I''m currently working on a backup strategy for my Xen domains, which I know has been discussed many times on this list. After looking at the various options, I''ve settled on creating LVM snapshots on the host (dom0) and centralizing all backups from it. This is easy to control, easy to do, allows me to continue running my guests during the process, and (despite some cautions I''ve read on the list) so far reliable for me. However, I''ve hit a point where the whole thing seems to fall apart: restoring files. I have to just be being dense about this, but I can''t find any way to copy a file BACK to the guest domain (short of either rebooting the guest or copying it across the network, neither of which is very practical. So here''s the deal. I create my backups by doing the following: lvcreate -L 50G -s -n guest-backup /dev/vg1/guest-disk mount -t ext3 -o ro /dev/vg1/guest-backup /mnt/snapshot This lets me copy off the backup files in a clean state. This works fine, so I then unmount/remove the snapshot. umount /mnt/snapshot/ lvremove -f /dev/vg1/guest-backup So far, so good. Now, let''s say I need to restore a file to that guest-disk partition. Eg., let''s say the /etc/fstab file on my guest somehow got corrupt and I want to restore a clean copy. How exactly do I do this? From what I''ve read of LVM, v2 includes read/write support. So, I''d think that I could do the following and it''d just work: lvcreate -L 50G -s -n guest-backup /dev/vg1/guest-disk mount -t ext3 -o rw /dev/vg1/guest-backup /mnt/snapshot cp /mnt/backup/guest/etc/fstab /mnt/snapshot/etc/fstab.restore umount /mnt/snapshot/ lvremove -f /dev/vg1/guest-backup From the host''s perspective, this works fine. However, if I then login to the guest, the new fstab.restore file does not exist. I''ve tried this multiple times using various different techniques, but I can never get the file to actually show up. Like I said, I must either be really dense or I''m just misunderstanding the meaning of "read/write" here, because the file is certainly not being written as I''d expect. Can anyone tell me what I''m doing wrong? If this just won''t work as I''d expect it, how else can I write a file from the host to a live guest? Surely there must be some way to do it... Thanks. -- Jared _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jared wrote:> From what I''ve read of LVM, v2 includes read/write support. So, I''d > think that I could do the following and it''d just work: > > lvcreate -L 50G -s -n guest-backup /dev/vg1/guest-disk > mount -t ext3 -o rw /dev/vg1/guest-backup /mnt/snapshot > cp /mnt/backup/guest/etc/fstab /mnt/snapshot/etc/fstab.restore > umount /mnt/snapshot/ > lvremove -f /dev/vg1/guest-backup >Dude, it doesn''t work that way. The way I see it, you''re writing data to /dev/vg1/guest-backup, but then you REMOVE the LV afterwards. And you expect it to show up on /dev/vg1/guest-disk?> Like I said, I must either be really dense or I''m just > misunderstanding the meaning of "read/write" here, because the file is > certainly not being written as I''d expect.The "read/write" part means you (should) be able to create a snapshot of an LV, and write new data to that snapshot. The data will then be available ONLY to the snapshot, not to the original LV. To accomplish what you''re looking for, you must copy the file using either scp (or some other network-file-transfer), or shutdown the guest and mount the LV on dom0. This is different from (lets say) Solaris Zones, where a non-global zone filesystem is visible from the global zone. In this case you can write files from the global zone and have the non-global zone see the new data. I believe it''s not recommended to do so, but it works, since both global and none global zone can have simultaneous access to the same filesystem. It won''t work with Xen. If you absolutely must have the "feature" above, you might want to look at solaris and brandZ zones. Basically it allows you to run some linux distros on top of solaris kernel, giving global zone and brandZ zone access to the same filesystem. Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha wrote:> Jared wrote: >> From what I''ve read of LVM, v2 includes read/write support. So, I''d >> think that I could do the following and it''d just work: >> >> lvcreate -L 50G -s -n guest-backup /dev/vg1/guest-disk >> mount -t ext3 -o rw /dev/vg1/guest-backup /mnt/snapshot >> cp /mnt/backup/guest/etc/fstab /mnt/snapshot/etc/fstab.restore >> umount /mnt/snapshot/ >> lvremove -f /dev/vg1/guest-backup >> > > Dude, it doesn''t work that way. > The way I see it, you''re writing data to /dev/vg1/guest-backup, but > then you REMOVE the LV afterwards. And you expect it to show up on > /dev/vg1/guest-disk?Don''t run the "mount". Use "xm" to export that LVM snapshot to the guest domain, and mount it *inside* the guest domain. Then unmount, unexport it, and flush the snapshot. Alternatively, you can completely shut down the guest and mount both partitions and copy things to the old guest partition, but I don''t think you want to do that. By the way, why are you using partition based LVM images, rather than disk based LVM images? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Mar 5, 2008 at 11:18 PM, Jared <list-xen@legroom.net> wrote:> file to actually show up. Like I said, I must either be really dense or I''m > just misunderstanding the meaning of "read/write" here, because the file is > certainly not being written as I''d expect.as Fajar has said, the R/W snapshots don''t work like that. being R/W means that you can write to the snapshot, so that you can have several versions of a volume, all a little different, all independently writable. IMO, the easiest way to copy back a file is simply using a network filesystem. you restore from backup to a file server, and read it from the DomU. if the DomU is totally unstable/unbootable/untrustable, then it shouldn''t be running, so you can mount its volume on Dom0, and rebuild it (using the backup) before starting up again. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 03/05/2008 11:44 PM, Fajar A. Nugraha wrote:> Dude, it doesn''t work that way. > The way I see it, you''re writing data to /dev/vg1/guest-backup, but then > you REMOVE the LV afterwards. And you expect it to show up on > /dev/vg1/guest-disk?OK, so I''m officially being dense. I can live with that. :-)> The "read/write" part means you (should) be able to create a snapshot of > an LV, and write new data to that snapshot. The data will then be > available ONLY to the snapshot, not to the original LV.I understand what you''re saying, and when dealing with normal filesystem mounts I''d fully expect that behavior, but the LVM snapshots are throwing me for a loop. There are two things that made me believe this would work: * What''s the purpose of allowing write support to a snapshot if the written files are not populated on the original volume? I don''t get the "benefit" of being able to write to a snapshot if the changes will be completely discarded. * Snapshots work, based on my very limited understanding at this point, on essentially caching changes made to the source volume while the snapshot exists, then flushing those changes to disk once the snapshot is removed. Based on that, and on the bullet above, I figured there may be some "reverse" caching or something (for lack of a better term) that would flush changes written to the snapshot back to the source volume as well.> To accomplish what you''re looking for, you must copy the file using > either scp (or some other network-file-transfer), or shutdown the guest > and mount the LV on dom0.That''s what I''m trying to avoid doing. Shutting down the guest is definitely not an option. I know I could do that and directly mount the volume from the host pretty easily, but I don''t want to interrupt the services running on that guest. scp has always been my fallback option, but I''m trying to come up with a more direct solution. Since I''m working with volumes created and managed on the host, it seems reasonable to assume that there should be some way to write data to the volumes.> This is different from (lets say) Solaris Zones, where a non-global zone > filesystem is visible from the global zone. In this case you can write > files from the global zone and have the non-global zone see the new > data. I believe it''s not recommended to do so, but it works, since both > global and none global zone can have simultaneous access to the same > filesystem. It won''t work with Xen.Interesting. I can''t say I have much desire to switch over to Solaris, though. :-) This isn''t an absolutely "must have" feature, it''d just be really nice. Thanks for the detailed response. It definitely helps clear some things up. -- Jared _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 03/06/2008 02:37 AM, Nico Kadel-Garcia wrote:> Don''t run the "mount". Use "xm" to export that LVM snapshot to the guest > domain, and mount it *inside* the guest domain. Then unmount, unexport > it, and flush the snapshot.This sounds like an interesting approach. I''ll have to look into it tonight and see if I can make it work. Thanks for the suggestion.> Alternatively, you can completely shut down the guest and mount both > partitions and copy things to the old guest partition, but I don''t think > you want to do that.Not at all. :-)> By the way, why are you using partition based LVM images, rather than > disk based LVM images?No, they are disk-based. I''m just used to describing these things in terms of partitions. This is my first experience with LVM (obviously), so I just haven''t adjusted to the new terminology yet. -- Jared _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jared, Jared wrote:> * What''s the purpose of allowing write support to a snapshot if the > written files are not populated on the original volume?For some use cases this is a good feature. However, it is of no interest in your use case, as you might have guessed by now. :-)> I don''t get the > "benefit" of being able to write to a snapshot if the changes will be > completely discarded.The writes will not be discarded. They are written to the snapshot. (Which, in YOUR use case, will be discarded after a while.)> ... Based on that, and on the bullet above, I figured there may > be some "reverse" caching or something (for lack of a better term) that > would flush changes written to the snapshot back to the source volume as > well.No, that is not the case.> ... Since I''m > working with volumes created and managed on the host, it seems > reasonable to assume that there should be some way to write data to the > volumes.No, not while the guest is running. Unless you are using a file system that can handle with writes from more than one host to the same block device. I don''t know of any that doesn''t use some network interconnect for managing the shared access. Good luck! BR /Martin Leben _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jared wrote:> On 03/05/2008 11:44 PM, Fajar A. Nugraha wrote: >> Dude, it doesn''t work that way. >> The way I see it, you''re writing data to /dev/vg1/guest-backup, but >> then you REMOVE the LV afterwards. And you expect it to show up on >> /dev/vg1/guest-disk? > > OK, so I''m officially being dense. I can live with that. :-) > >> The "read/write" part means you (should) be able to create a snapshot >> of an LV, and write new data to that snapshot. The data will then be >> available ONLY to the snapshot, not to the original LV. > > I understand what you''re saying, and when dealing with normal > filesystem mounts I''d fully expect that behavior, but the LVM > snapshots are throwing me for a loop. There are two things that made > me believe this would work: > > * What''s the purpose of allowing write support to a snapshot if the > written files are not populated on the original volume? I don''t get > the "benefit" of being able to write to a snapshot if the changes will > be completely discarded. > > * Snapshots work, based on my very limited understanding at this > point, on essentially caching changes made to the source volume while > the snapshot exists, then flushing those changes to disk once the > snapshot is removed. Based on that, and on the bullet above, I > figured there may be some "reverse" caching or something (for lack of > a better term) that would flush changes written to the snapshot back > to the source volume as well. > >> To accomplish what you''re looking for, you must copy the file using >> either scp (or some other network-file-transfer), or shutdown the >> guest and mount the LV on dom0. > > That''s what I''m trying to avoid doing. Shutting down the guest is > definitely not an option. I know I could do that and directly mount > the volume from the host pretty easily, but I don''t want to interrupt > the services running on that guest. scp has always been my fallback > option, but I''m trying to come up with a more direct solution. Since > I''m working with volumes created and managed on the host, it seems > reasonable to assume that there should be some way to write data to > the volumes.Because you can *VERY QUICKLY* make a snapshot, even of a live environment, and then do more painful or slower options on that snapshot while the live fileystem is doing whatever it needs to do. This includes making tape backups, analyzing the data of a database without having to lock it while doing your own work and having it change under you, etc. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 03/06/08 20:13, Nico Kadel-Garcia wrote:> Because you can *VERY QUICKLY* make a snapshot, even of a live > environment, and then do more painful or slower options on that snapshot > while the live fileystem is doing whatever it needs to do. This includes > making tape backups, analyzing the data of a database without having to > lock it while doing your own work and having it change under you, etc.Oh, I fully understand that part (the ''read'' part). That''s exactly what attracted me to this solution to begin with. It''s the ''write'' part that didn''t really make a whole lot of sense, but that''s apparently just because I''m not trying to use it as it''s meant to be used. -- Jared _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
roberto_2006 2008-03-07 发件人： Jared 发送时间： 2008-03-07 13:18:28 收件人： xen-users@lists.xensource.com 抄送： 主题： Re: [Xen-users] restoring files to guest domains On 03/06/08 20:13, Nico Kadel-Garcia wrote:> Because you can *VERY QUICKLY* make a snapshot, even of a live > environment, and then do more painful or slower options on that snapshot > while the live fileystem is doing whatever it needs to do. This includes > making tape backups, analyzing the data of a database without having to > lock it while doing your own work and having it change under you, etc.Oh, I fully understand that part (the 'read' part). That's exactly what attracted me to this solution to begin with. It's the 'write' part that didn't really make a whole lot of sense, but that's apparently just because I'm not trying to use it as it's meant to be used. -- Jared _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jared wrote:> On 03/06/08 20:13, Nico Kadel-Garcia wrote: >> Because you can *VERY QUICKLY* make a snapshot, even of a live >> environment, and then do more painful or slower options on that >> snapshot while the live fileystem is doing whatever it needs to do. >> This includes making tape backups, analyzing the data of a database >> without having to lock it while doing your own work and having it >> change under you, etc. > > Oh, I fully understand that part (the ''read'' part). That''s exactly > what attracted me to this solution to begin with. It''s the ''write'' > part that didn''t really make a whole lot of sense, but that''s > apparently just because I''m not trying to use it as it''s meant to be > used.Well, you can write to it too, but only as much as you''ve set aside image space for when doing the snapshot. It''s also useful for building OS images: snapshot a good system, tweak the snapshot as needed, and copy *THAT* to a new system. SELinux can be an issue, but I''ve worked around it by deleting and re-installing SELinux on the fly on the target system. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Friday 07 March 2008 04:03:27 am Nico Kadel-Garcia wrote:> Well, you can write to it too, but only as much as you''ve set aside > image space for when doing the snapshot. It''s also useful for building > OS images: snapshot a good system, tweak the snapshot as needed, and > copy *THAT* to a new system. SELinux can be an issue, but I''ve worked > around it by deleting and re-installing SELinux on the fly on the target > system.Setting SELinux to ''permissive'' wasn''t sufficient? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
jim burns wrote:> On Friday 07 March 2008 04:03:27 am Nico Kadel-Garcia wrote: > >> Well, you can write to it too, but only as much as you''ve set aside >> image space for when doing the snapshot. It''s also useful for building >> OS images: snapshot a good system, tweak the snapshot as needed, and >> copy *THAT* to a new system. SELinux can be an issue, but I''ve worked >> around it by deleting and re-installing SELinux on the fly on the target >> system. >> > > Setting SELinux to ''permissive'' wasn''t sufficient? >If you like your system log files filled with thousands and thousands of lines daily of useless SELinux whinging, sure. But using SELinux in "permissive" mode should be for debugging and eventually turning SELinux on, not for stable running environments. Otherwise, it''s very difficult to sort out which whinging lines actually mean something you should address. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users