[Lxc-users] lxc containers as backup 'replicas'
Following the pretty successful tests** I've been making of using lxc containers I'd be grateful for some advice on using lxc containers as backp 'replicas' of running machines, to bring up in case the main host fails. **(I've been on the list to discuss routing problems which I've solved temporarily by turning off kernel ethernet filtering -- still an issue in discussion). There are 4 parts to a running machine that I will need to replicate to a lxc container, which I intend to do nightly. These are: 1. etc configuration (we back config files up through etckeeper) 2. binaries (we're happy with a dpkg -l listings here) 3. run-time config for web apps (we back up through a file backup) 4. database backup (backed up via log shipping) I'd be grateful to know if it is possible to sync 1. and 3. into the container when it is not running. In other words, to simply update the config files in /var/lib/lxc/container/rootfs/etc, for example? On another point I'd also like to know of the recommended way of using another mount point for lxc containers and the dpkg cache. For example, I wish to hold my containers in /dev/sdb/ mounted on /containers. Should I symlink /var/lib/lxc/ to this mount point? Finally I'd be grateful to learn of people's experiences with btrfs for snapshotting and managing containers. I personally use it for my laptop backups, but my host server is on a 3.2.0-4-amd64 kernel which is pretty old by btrfs standards. Rory -- Rory Campbell-Lange r...@campbell-lange.net -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc containers as backup 'replicas'
Quoting Rory Campbell-Lange (r...@campbell-lange.net): Following the pretty successful tests** I've been making of using lxc containers I'd be grateful for some advice on using lxc containers as backp 'replicas' of running machines, to bring up in case the main host fails. **(I've been on the list to discuss routing problems which I've solved temporarily by turning off kernel ethernet filtering -- still an issue in discussion). There are 4 parts to a running machine that I will need to replicate to a lxc container, which I intend to do nightly. These are: 1. etc configuration (we back config files up through etckeeper) 2. binaries (we're happy with a dpkg -l listings here) 3. run-time config for web apps (we back up through a file backup) 4. database backup (backed up via log shipping) I'd be grateful to know if it is possible to sync 1. and 3. into the container when it is not running. In other words, to simply update the config files in /var/lib/lxc/container/rootfs/etc, for example? If the source is still running then I suppose depending on the application some of the source files could be in a transient, inconsistent state. On another point I'd also like to know of the recommended way of using another mount point for lxc containers and the dpkg cache. For example, I wish to hold my containers in /dev/sdb/ mounted on /containers. Should I symlink /var/lib/lxc/ to this mount point? If you're on a new enough lxc (i.e. 0.9.0) I'd recommend using lxcpath. You can set 'lxcpath = /srv/lxc' in /etc/lxc/lxc.conf, then all containers will be created and run from /srv/lxc instead of /var/lib/lxc. Or you can just add '-P /srv/lxc' to all lxc-* commands. Finally I'd be grateful to learn of people's experiences with btrfs for snapshotting and managing containers. I personally use it for my laptop backups, but my host server is on a 3.2.0-4-amd64 kernel which is pretty old by btrfs standards. yeah I don't know that I'd trust it under 3.2. I think 3.5 is where it stopped losing data for me. But best to run some tests. When it failed me, it generally did so after one or two subvolume commands. -serge -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc containers as backup 'replicas'
On Wed, Jun 5, 2013 at 6:50 PM, Rory Campbell-Lange r...@campbell-lange.net wrote: There are 4 parts to a running machine that I will need to replicate to a lxc container, which I intend to do nightly. These are: 1. etc configuration (we back config files up through etckeeper) 2. binaries (we're happy with a dpkg -l listings here) 3. run-time config for web apps (we back up through a file backup) 4. database backup (backed up via log shipping) I'd be grateful to know if it is possible to sync 1. and 3. into the container when it is not running. In other words, to simply update the config files in /var/lib/lxc/container/rootfs/etc, for example? Should be possible. However, personally I'd just forget for a moment that the backup will be run on lxc and do the same things I'd do on a normal machine. In my case, I'd use zfs snapshot and send|receive (yes, you can use zfs for root). In your case it'd probably be rsync or whatever you're happy with. On another point I'd also like to know of the recommended way of using another mount point for lxc containers and the dpkg cache. For example, I wish to hold my containers in /dev/sdb/ mounted on /containers. Should I symlink /var/lib/lxc/ to this mount point? I'm pretty sure there were problems wiith that on some versions on lxc (can't remember the exact details, sorry). A bind mount would probably be safer. Finally I'd be grateful to learn of people's experiences with btrfs for snapshotting and managing containers. I personally use it for my laptop backups, but my host server is on a 3.2.0-4-amd64 kernel which is pretty old by btrfs standards. Is there a particular requirement for that version of kernel? In RHEL/Centos/Ubuntu you can often use prebuilt latest vanilla kernel with only minimum change required (although the distro won't offically support it, obviously). If you're stuck with kernel 3.2 then I'd say use zfs. The devs take extra care to make sure it works well on RHEL6 (with its ancient 2.6.32 kernel), and should work on all kernel from that version up to 3.9. -- Fajar -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc containers as backup 'replicas'
On 05/06/13, Serge Hallyn (serge.hal...@ubuntu.com) wrote: Quoting Rory Campbell-Lange (r...@campbell-lange.net): On another point I'd also like to know of the recommended way of using another mount point for lxc containers and the dpkg cache. For example, I wish to hold my containers in /dev/sdb/ mounted on /containers. Should I symlink /var/lib/lxc/ to this mount point? If you're on a new enough lxc (i.e. 0.9.0) I'd recommend using lxcpath. You can set 'lxcpath = /srv/lxc' in /etc/lxc/lxc.conf, then all containers will be created and run from /srv/lxc instead of /var/lib/lxc. Or you can just add '-P /srv/lxc' to all lxc-* commands. I'm on Debian Wheezy which has 0.8.0~rc1-8+deb7u1. Looks like I should use the -P flag. Finally I'd be grateful to learn of people's experiences with btrfs for snapshotting and managing containers. I personally use it for my laptop backups, but my host server is on a 3.2.0-4-amd64 kernel which is pretty old by btrfs standards. yeah I don't know that I'd trust it under 3.2. I think 3.5 is where it stopped losing data for me. But best to run some tests. When it failed me, it generally did so after one or two subvolume commands. Cheers for those notes. Rory -- Rory Campbell-Lange r...@campbell-lange.net -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc containers as backup 'replicas'
On 05/06/13, Fajar A. Nugraha (l...@fajar.net) wrote: On Wed, Jun 5, 2013 at 6:50 PM, Rory Campbell-Lange r...@campbell-lange.net wrote: I'd be grateful to know if it is possible to sync 1. and 3. into the container when it is not running. In other words, to simply update the config files in /var/lib/lxc/container/rootfs/etc, for example? ... However, personally I'd just forget for a moment that the backup will be run on lxc and do the same things I'd do on a normal machine. In my case, I'd use zfs snapshot and send|receive (yes, you can use zfs for root). In your case it'd probably be rsync or whatever you're happy with. Are there any files that shouldn't percolate between a normal running server's /etc/ and one in an lxc container? On another point I'd also like to know of the recommended way of using another mount point for lxc containers and the dpkg cache. For example, I wish to hold my containers in /dev/sdb/ mounted on /containers. Should I symlink /var/lib/lxc/ to this mount point? I'm pretty sure there were problems wiith that on some versions on lxc (can't remember the exact details, sorry). A bind mount would probably be safer. do you mean the exivalent of 'mount /dev/sdb1 /var/lib/lxc/' ? Finally I'd be grateful to learn of people's experiences with btrfs for snapshotting and managing containers. I personally use it for my laptop backups, but my host server is on a 3.2.0-4-amd64 kernel which is pretty old by btrfs standards. Is there a particular requirement for that version of kernel? In RHEL/Centos/Ubuntu you can often use prebuilt latest vanilla kernel with only minimum change required (although the distro won't offically support it, obviously). If you're stuck with kernel 3.2 then I'd say use zfs. The devs take extra care to make sure it works well on RHEL6 (with its ancient 2.6.32 kernel), and should work on all kernel from that version up to 3.9. I'm on Debian stable and I like being there for production machines (even though this is a backup machine). I'm not sure about the availability of a 3.8+ kernel on Debian. I'm tempted by zfs but worried about its likely cohabitation -- licence-wise -- over time with the kernel. Thanks for your comments Rory -- Rory Campbell-Lange r...@campbell-lange.net -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc containers as backup 'replicas'
On Thu, Jun 6, 2013 at 2:57 AM, Rory Campbell-Lange r...@campbell-lange.net wrote: In my case, I'd use zfs snapshot and send|receive (yes, you can use zfs for root). In your case it'd probably be rsync or whatever you're happy with. Are there any files that shouldn't percolate between a normal running server's /etc/ and one in an lxc container? Newer versions of Ubuntu has pretty tight lxc integration, in that if you use an existing root on lxc, it would mostly just work. The exceptions are mostly stuff that you'd need to take care of even on normal servers, like networking config. On another point I'd also like to know of the recommended way of using another mount point for lxc containers and the dpkg cache. For example, I wish to hold my containers in /dev/sdb/ mounted on /containers. Should I symlink /var/lib/lxc/ to this mount point? I'm pretty sure there were problems wiith that on some versions on lxc (can't remember the exact details, sorry). A bind mount would probably be safer. do you mean the exivalent of 'mount /dev/sdb1 /var/lib/lxc/' ? mount --bind /containers /var/lib/lxc Finally I'd be grateful to learn of people's experiences with btrfs for snapshotting and managing containers. I personally use it for my laptop backups, but my host server is on a 3.2.0-4-amd64 kernel which is pretty old by btrfs standards. Is there a particular requirement for that version of kernel? In RHEL/Centos/Ubuntu you can often use prebuilt latest vanilla kernel with only minimum change required (although the distro won't offically support it, obviously). If you're stuck with kernel 3.2 then I'd say use zfs. The devs take extra care to make sure it works well on RHEL6 (with its ancient 2.6.32 kernel), and should work on all kernel from that version up to 3.9. I'm on Debian stable and I like being there for production machines (even though this is a backup machine). I'm not sure about the availability of a 3.8+ kernel on Debian. One way to test is to use latest kernel from Debian testing, which should be 3.9. That is, if you're REALLY set on using btrfs I'm tempted by zfs but worried about its likely cohabitation -- licence-wise -- over time with the kernel. More details about this should be on zfsonlinux's list, but suffice to say that ZoL is distributed separately from the kernel (similar to nvidia's kernel module), and that is unlikely to change. Looking at its current devs and contributors, personally I'm pretty sure ZoL will still be around for quite a while. -- Fajar -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
