Re: [j-nsp] Steel-Belted RADIUS backups
Hi there, You might consider using RAID mirroring if your servers support it :) /ET On 8/30/13 12:42 PM, Jed Laundry jlaun...@jlaundry.com wrote: If it's Linux, are you using LVM as a storage layer? LVM snapshots are your friend for making a consistent backup, regardless of if you use a tar script or VM snapshot/image. Thanks, Jed. Sent from a mobile device. On 29/08/2013 11:12 pm, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi all, Does anyone out there use SBR? We have the Global Enterprise Edition (GEE) version v6.1.7 running on Linux. I'm putting something in place to back up SBR itself; currently we just tar up /opt/JNPRsbr/radius (after stopping sbrd) but it's occurred to me that we have never tested a recovery using this method. JTAC are telling me there is no automated way to perform the XML export function normally performed in the GUI. The product docs don't make it clear whether taking a copy of everything in /opt/JNPRsbr/radius/ is enough, or whether the XML export is also required. Looking at what the supplied install/upgrade scripts do, it's just a recursive 'cp' with some unnecessary folders excluded. We also take backups of the VM guest that's running SBR but I'm not familiar enough with SBR's back-end databases to know whether that results in a recoverable data set; there'll be open files for sure (hence the stop;tar;start method described above). What do you do? use FreeRADIUS instead is a valid but unwelcome response :-)) Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Steel-Belted RADIUS backups
On Aug 30, 2013 1:46 AM, Jed Laundry jlaun...@jlaundry.com wrote: If it's Linux, are you using LVM as a storage layer? LVM snapshots are your friend for making a consistent backup, regardless of if you use a tar script or VM snapshot/image. Unless developers have made major structural changes to LVM snapshots they're nearly useless. They require large swaths of contiguous kernel RAM for the CoW bitmap so once a machine is running for a while and thus has fragmented its RAM free space you end up with LVM bailing out while trying to snapshot. The other side of that is if your snapshot routine doesn't shutdown services and unmount the filesystem you're essentially snapshotting a crashed server and hoping filesystem and database recovery goes well when you restore that backup Thanks, Jed. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Steel-Belted RADIUS backups
If it's Linux, are you using LVM as a storage layer? LVM snapshots are your friend for making a consistent backup, regardless of if you use a tar script or VM snapshot/image. Thanks, Jed. Sent from a mobile device. On 29/08/2013 11:12 pm, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi all, Does anyone out there use SBR? We have the Global Enterprise Edition (GEE) version v6.1.7 running on Linux. I'm putting something in place to back up SBR itself; currently we just tar up /opt/JNPRsbr/radius (after stopping sbrd) but it's occurred to me that we have never tested a recovery using this method. JTAC are telling me there is no automated way to perform the XML export function normally performed in the GUI. The product docs don't make it clear whether taking a copy of everything in /opt/JNPRsbr/radius/ is enough, or whether the XML export is also required. Looking at what the supplied install/upgrade scripts do, it's just a recursive 'cp' with some unnecessary folders excluded. We also take backups of the VM guest that's running SBR but I'm not familiar enough with SBR's back-end databases to know whether that results in a recoverable data set; there'll be open files for sure (hence the stop;tar;start method described above). What do you do? use FreeRADIUS instead is a valid but unwelcome response :-)) Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Steel-Belted RADIUS backups
Hi all, Does anyone out there use SBR? We have the Global Enterprise Edition (GEE) version v6.1.7 running on Linux. I'm putting something in place to back up SBR itself; currently we just tar up /opt/JNPRsbr/radius (after stopping sbrd) but it's occurred to me that we have never tested a recovery using this method. JTAC are telling me there is no automated way to perform the XML export function normally performed in the GUI. The product docs don't make it clear whether taking a copy of everything in /opt/JNPRsbr/radius/ is enough, or whether the XML export is also required. Looking at what the supplied install/upgrade scripts do, it's just a recursive 'cp' with some unnecessary folders excluded. We also take backups of the VM guest that's running SBR but I'm not familiar enough with SBR's back-end databases to know whether that results in a recoverable data set; there'll be open files for sure (hence the stop;tar;start method described above). What do you do? use FreeRADIUS instead is a valid but unwelcome response :-)) Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Steel-Belted RADIUS backups
How about a MAG running IC + RADIUS License? It's not FreeRADIUS :) In all seriousness perhaps you can script an export using the LDAP tools, and import that back in? http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/ html/LDAPConfig6.html#334279 On 8/29/13 5:10 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi all, Does anyone out there use SBR? We have the Global Enterprise Edition (GEE) version v6.1.7 running on Linux. I'm putting something in place to back up SBR itself; currently we just tar up /opt/JNPRsbr/radius (after stopping sbrd) but it's occurred to me that we have never tested a recovery using this method. JTAC are telling me there is no automated way to perform the XML export function normally performed in the GUI. The product docs don't make it clear whether taking a copy of everything in /opt/JNPRsbr/radius/ is enough, or whether the XML export is also required. Looking at what the supplied install/upgrade scripts do, it's just a recursive 'cp' with some unnecessary folders excluded. We also take backups of the VM guest that's running SBR but I'm not familiar enough with SBR's back-end databases to know whether that results in a recoverable data set; there'll be open files for sure (hence the stop;tar;start method described above). What do you do? use FreeRADIUS instead is a valid but unwelcome response :-)) Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
