hey, I have an application for drbd replication between a pair of EL6 servers, and I just realized that drbd is no longer built in.
googling found me this blog on doing it using ElRepo distributions... http://www.broexperts.com/2012/06/how-to-install-drbd-on-centos-6-2/
is that still best practice? or is there a better distribution?
or really... my application is a BackupPC server replicating its backup volume to a standby server (hey, no backup is really a backup, unless there is a backup of the backup, right?). is there a better/alternate way of maintaining a mirror of a backupPC volume than drbd... the backup volume is initially 8TB and could well grow to 3 times that over time. its stored on an XFS file system, under LVM, on striped raid6 volumes.
On Tue, Feb 26, 2013 at 1:44 PM, John R Pierce pierce@hogranch.com wrote:
hey, I have an application for drbd replication between a pair of EL6 servers, and I just realized that drbd is no longer built in.
googling found me this blog on doing it using ElRepo distributions... http://www.broexperts.com/2012/06/how-to-install-drbd-on-centos-6-2/
is that still best practice?
Absolutely.
or is there a better distribution?
No.
Akemi
On Tue, Feb 26, 2013 at 4:44 PM, John R Pierce pierce@hogranch.com wrote:
hey, I have an application for drbd replication between a pair of EL6 servers, and I just realized that drbd is no longer built in.
googling found me this blog on doing it using ElRepo distributions... http://www.broexperts.com/2012/06/how-to-install-drbd-on-centos-6-2/
is that still best practice?
Yes.
or is there a better distribution?
No
or really... my application is a BackupPC server replicating its backup volume to a standby server (hey, no backup is really a backup, unless there is a backup of the backup, right?). is there a better/alternate way of maintaining a mirror of a backupPC volume than drbd... the backup volume is initially 8TB and could well grow to 3 times that over time. its stored on an XFS file system, under LVM, on striped raid6 volumes.
DRBD is a distributed block device. It's very useful for offering HA services, but much like raid, drbd isn't a backup. If I had two boxes for doing my backups, I'd use a file level replication (like rsync) to "backup up the backup" (or better yet, ship a snapshot of a COW fs you ran an fs check on). It's too easy to trash a volume with an rm / fs bug / split brain. It would make it harder to do an auto failover, but i would be safer. If I miss a backup because the primary is offline, I miss one backup cycle. If I screw up and delete a backup off the drbd volume (or I hit a bug that corrupts the fs), I could lose my entire backup set. I could even treat the second box as a monthly "offline" box that I unplug from the network as "added protection against worms and malware" or some other nonsense like that if I had to justify it's existence.
That being said, if you have a requirement that your backup solution is up five nines, then yeah, use drbd / pacemaker, it's just not a use case I see very often.
Best, Patrick
On 2/26/2013 3:03 PM, Patrick Flaherty wrote:
That being said, if you have a requirement that your backup solution is up five nines, then yeah, use drbd / pacemaker, it's just not a use case I see very often.
don't have anywhere near that sort of uptime requirements, but when data starts spiralling out into the multi-terabytes with billions of file links, rsync is painfully slow.
the use case is more like, if the primary backup server fails, I'd like to have the secondary backup server running within a few hours of futzing with the existing backups available for recovery.
maybe I should use backupPC's archiving feature, but if I have to restore 20TB or whatever of files and links from an archive, that could well take the better part of a week.
the way I figure it, drbd would give me a backup copy of the backup system thats ready for near immediate use. failover would be a manual process, but simple and quick (stop drbd, mount the archive, start the standby backup PC server)..
On Tue, Feb 26, 2013 at 5:26 PM, John R Pierce pierce@hogranch.com wrote:
don't have anywhere near that sort of uptime requirements, but when data starts spiralling out into the multi-terabytes with billions of file links, rsync is painfully slow.
Yes, the one problem with backuppc is that the number of hardlinks it uses to de-dup the data makes it a big problem to copy its archive as anything but an image-type copy.
the use case is more like, if the primary backup server fails, I'd like to have the secondary backup server running within a few hours of futzing with the existing backups available for recovery.
maybe I should use backupPC's archiving feature, but if I have to restore 20TB or whatever of files and links from an archive, that could well take the better part of a week.
The simple approach is to run another independent instance of backuppc, but you may run into problems with the timing if you have a small backup window.
the way I figure it, drbd would give me a backup copy of the backup system thats ready for near immediate use. failover would be a manual process, but simple and quick (stop drbd, mount the archive, start the standby backup PC server)..
That should work, but what happens if they ever get out of sync? How long will it take drbd to catch up with something that size?
On 2/26/2013 3:36 PM, Les Mikesell wrote:
That should work, but what happens if they ever get out of sync? How long will it take drbd to catch up with something that size?
the initial sync of the 8TB starting volumes is looking to be a 460 hour affair. yeouch. I might have to rethink this.
I also haven't investigated yet if drbd devices can be 'grown' ... pause replication, lvextend slave and master, xfs_grow the master, and resume replication? or is that too easy and it won't work...
On 2/26/2013 4:17 PM, Steve Thompson wrote:
On Tue, 26 Feb 2013, John R Pierce wrote:
the initial sync of the 8TB starting volumes is looking to be a 460 hour affair.
Something wrong here. That's only 5 MB/sec; I did an initial sync of a 10TB volume in less than a day (dual bonded gigabits, dedicated).
I have it up to about 120MB/sec, so now its 20 hours. I didn't set syncer properly.
Hello all, So here is my problem. I did some searches online about this and was a bit confused with regard to something. There error I get when I run yum begins with " file:///media/CentOS/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/CentOS/repodata/repomd.xml" I'll include the full error log below. When I did some searching online, it said to check the yum.conf file. When I do that, inside /etc When I open that file, and scroll down, it says that I need to add the repos to that file or to add them to add them to files named file.repo in /etc/yum.repos.d Those repos do exist and as example, here is what I see in the file virtualbox.repo which is /etc/yum.repos.d/ The contents of that file are: [virtualbox] name=Oracle Linux / RHEL / CentOS-$releasever / $basearch - VirtualBox baseurl=http://download.virtualbox.org/virtualbox/rpm/el/$releasever/$basear ch enabled=1 gpgcheck=1 gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc
So, from the error log below, can I put this: base: mirror.cogentco.com c6-media: centosplus: mirror.dattobackup.com contrib: mirrors.lga7.us.voxel.net extras: centos.aol.com rpmforge: mirror.us.leaseweb.net updates: mirror.symnds.com
into the /etc/yum.conf just as it appears in my copy and paste just above? And then it might work? Still curious why it didn't work with the files.repo respository files. Ok, the full error listing is next, thanks in advance for any help:
Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from cached hostfile * base: mirror.cogentco.com * c6-media: * centosplus: mirror.dattobackup.com * contrib: mirrors.lga7.us.voxel.net * extras: centos.aol.com * rpmforge: mirror.us.leaseweb.net * updates: mirror.symnds.com adobe-linux-x86_64 | 951 B 00:00 base | 3.7 kB 00:00 file:///media/CentOS/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/CentOS/repodata/repomd.xml Trying other mirror. file:///media/cdrecorder/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrecorder/repodata/repomd.xml Trying other mirror. file:///media/cdrom/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrom/repodata/repomd.xml Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: c6-media. Please verify its path and try again
Bruce
_______________________________________________________ Bruce Whealton - Web Design/Development/Programming Future Wave Web Development: http://futurewaveonline.com Developing for the Desktop as well as for Mobile Devices - Smartphones/Tablets Call 919-636-5809 _______________________________________________________
On 2/27/2013 5:21 PM, Bruce Whealton wrote:
file:///media/CentOS/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/CentOS/repodata/repomd.xml Trying other mirror. file:///media/cdrecorder/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrecorder/repodata/repomd.xml Trying other mirror. file:///media/cdrom/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrom/repodata/repomd.xml Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: c6-media. Please verify its path and try again
did you specify to enable the c6-media repository on your yum command line? c6-media is a reference to the centos6 DVD, and its looking to see if its mounted in /media/CentOS or /media/cdrom or /media/cdrecorder
I've /never/ messed with c6-media, as I don't use disks hardly ever, and I'd rather get the latest rpms from the update respositories.
Oh, ok. But I didn't specify to use c6-media? I was just using the command yum update or yum install php* How do I tell it not to use c6-media? Thanks, Bruce -----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of John R Pierce Sent: Wednesday, February 27, 2013 8:30 PM To: centos@centos.org Subject: Re: [CentOS] Newbie - yum update and repos problems
On 2/27/2013 5:21 PM, Bruce Whealton wrote:
file:///media/CentOS/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/CentOS/repodata/repomd.xml Trying other mirror. file:///media/cdrecorder/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrecorder/repodata/repomd.xml Trying other mirror. file:///media/cdrom/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrom/repodata/repomd.xml Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: c6-media. Please verify its path and try again
did you specify to enable the c6-media repository on your yum command line? c6-media is a reference to the centos6 DVD, and its looking to see if its mounted in /media/CentOS or /media/cdrom or /media/cdrecorder
I've /never/ messed with c6-media, as I don't use disks hardly ever, and I'd rather get the latest rpms from the update respositories.
On Thu, Feb 28, 2013 at 10:14 AM, Bruce Whealton <bruce@futurewaveonline.com
wrote:
Oh, ok. But I didn't specify to use c6-media? I was just using the command yum update or yum install php* How do I tell it not to use c6-media?
Check for the media to be defined in your yum repo files.
/etc/yum.repos.d/ /etc/yum.repos.d/CentOS-Base.repo
Just like John Pierce, I rarely if ever use the CentOS ISOs ... my installs are all PXE booted kickstart installs.
Images ready for pxe booting... http://mirrors.kernel.org/centos/6.3/os/x86_64/images/pxeboot/
Thanks,
Bruce -----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of John R Pierce Sent: Wednesday, February 27, 2013 8:30 PM To: centos@centos.org Subject: Re: [CentOS] Newbie - yum update and repos problems
On 2/27/2013 5:21 PM, Bruce Whealton wrote:
file:///media/CentOS/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/CentOS/repodata/repomd.xml Trying other mirror. file:///media/cdrecorder/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrecorder/repodata/repomd.xml Trying other mirror. file:///media/cdrom/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/cdrom/repodata/repomd.xml Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: c6-media. Please verify its path and try again
did you specify to enable the c6-media repository on your yum command line? c6-media is a reference to the centos6 DVD, and its looking to see if its mounted in /media/CentOS or /media/cdrom or /media/cdrecorder
I've /never/ messed with c6-media, as I don't use disks hardly ever, and I'd rather get the latest rpms from the update respositories.
-- john r pierce 37N 122W somewhere on the middle of the left coast
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wednesday 27 February 2013, "Bruce Whealton" bruce@futurewaveonline.com wrote:
So here is my problem. I did some searches online about thisand was a bit confused with regard to something. There error I get when I run yum begins with " file:///media/CentOS/repodata/repomd.xml: [Errno 14] Could not open/read file:///media/CentOS/repodata/repomd.xml"
The file /etc/yum.repos.d/CentOS-Media.repo has a line that says enabled=0 by default. Did you change it to enabled=1?
I also haven't investigated yet if drbd devices can be 'grown' ... pause replication, lvextend slave and master, xfs_grow the master, and resume replication? or is that too easy and it won't work...
They can be grown (I used it for static image store on the Sky Entertainment websites) but I haven't tried it online ... Only increasing the partitions used for the backing devices offline...
On 2013-02-26, John R Pierce pierce@hogranch.com wrote:
the use case is more like, if the primary backup server fails, I'd like to have the secondary backup server running within a few hours of futzing with the existing backups available for recovery.
If you're doing something rsync-like, and if your buildings are close, you could simply move the backup server to the primary server's location, reconfigure the network interface, and drop it in as a replacement for the dead fileserver. That might be safer than risking a previously-mentioned fumblefingers.
In that case, you might want a backup of the backup machine, so that if you deploy the backup in this way, it doesn't become a single point of failure. This might be more of a hassle than you want to deal with.
--keith
-
Akemi Yagi -
Bruce Whealton -
James Hogarth -
John R Pierce -
Keith Keller -
Les Mikesell -
Patrick Flaherty -
SilverTip257 -
Steve Thompson -
Yves Bellefeuille