This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 471953 - [RFE] - Provide an equal to Solaris 'flar' such as System Imager Suite in RHEL
[RFE] - Provide an equal to Solaris 'flar' such as System Imager Suite in RHEL
Status: CLOSED DUPLICATE of bug 1059196
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: distribution (Show other bugs)
7.0
All Linux
medium Severity medium
: beta
: 7.0
Assigned To: RHEL Product and Program Management
Ondrej Hudlicky
: FutureFeature, Triaged
Depends On:
Blocks: 860099 1044717 729785
  Show dependency treegraph
 
Reported: 2008-11-17 15:37 EST by Stuart R. Kirk
Modified: 2014-03-04 16:31 EST (History)
32 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-04 16:31:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 27531 None None None 2012-07-04 16:06:41 EDT

  None (edit)
Description Stuart R. Kirk 2008-11-17 15:37:50 EST
Description of problem:

In Red Hat Enterprise Linux there is no equivalent to the Solaris "flar" utility which allows a user to take a flash image backup of a system and offload it to an archive server, or re-deploy it as a "golden-image" to many systems in lieu of kickstarting.  

To solve this issue with RHEL, System Imager Suite (http://www.systemimager.org) has been installed to perform the same functions with a great deal of success. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Bill Nottingham 2008-11-19 12:20:27 EST
What sort of features are needed around this? Does it need to adjust to hardware changes on re-imaging?  Can it be accomplished by the moving of virt images?
Comment 2 Stuart R. Kirk 2008-11-19 12:40:36 EST
I am the Professional Services consultant on site with Eli Lilly in Indianapolis.  Presently, in their Solaris environment, when they wish to perform a patch update on their systems, they perform a "flar" (flash archive) backup which in essence offloads the entire contents of the local disk to an image file.  From there, if the patch process is not successful, the image archive can be restored putting the system back in the exact same condition it was in prior to the patch process starting.

In RHEL, there is no equal to this with the exception of LVM snapshotting, and virtualization.  In this environment, however, neither of these choices are options and as such we would like to be able to initiate the backup (imaging) of local disks on a server and subsequent offload of that image to another server.  In the event of a failure during RHEL patching, the server can be rebooted and given a custom boot ISO that will call the saved image from the image server and automatically re-provision and reload the server to its original pre-patch state.

The other useful item that is now present is the ability to take a server image and offload it and roll it out to many new systems thus acting as an alternative to kickstart whereby the "golden image" being dropped on the new servers is configured precisely in every day for the application.

System Imager Suite has been tested with image backup and recovery and also backup and restore to/from HP DL380 to/from HP DL580 systems where it has performed just as expected regardless of the different hardware.
Comment 8 Greg A 2008-12-05 14:05:47 EST
Can you please provide status on this request?  We have a large installation base of Solaris servers and we'd like to know Red Hat will provide us this functionality in future releases.

Thank you!
Comment 28 RHEL Product and Program Management 2011-07-05 20:55:37 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 31 Denise Dumas 2011-07-29 08:22:32 EDT
Yum is integrated with LVM snapshots as of 6.1, with improved documentation available in 6.2 manuals

RHEL customers can find a knowledge base article describing how to use the feature.
Comment 32 Jeremy West 2011-09-28 01:04:43 EDT
Hi Denise.  Yum/LVM snapshot'ing will not solve the entirety of the many customer requests here.  LVM snapshots work only at an LVM layer and not at the disk layer which is what most customers are looking for. Additionally LVM snapshots aren't very good for performance situations unless the snapshot is released during heavy I/O use.  Also, I'm not really sure it's possible to take an LVM snapshot and use it to image a new system.
Comment 34 Greg A 2011-10-01 01:47:38 EDT
RH is really missing the boat here.  This same topic is being discussed in the Customer Groups on RH's portal.  As more and more customers migrate from Legacy Unix they are looking for this exact functionality.  As Jeremy notes LVM does not cut it.  We need a disk level tool that can be executed real time.  That's precisely what System Imager does.  Honestly, though if RH refuses to look a gift horse in the mouth then the customer would be happy with another solution.  Just offer one that  provides real time disk based images that can be used for DR purposes.  That's what FLAR has been providing to our enterprise for the last 10+ years.
Comment 45 Terry Bowling 2014-02-18 12:59:58 EST
I've added additional notes and info on Rear to BZ 1059196.

Maybe that should be our primary focus and these others could be closed as duplicates?
Comment 46 Frank Hirtz 2014-03-04 16:31:34 EST
I'm fine with that strategy. This client is largely agnostic with regard to which solution is offered provided that there is one which is featureful (which REAR is).

*** This bug has been marked as a duplicate of bug 1059196 ***

Note You need to log in before you can comment on or make changes to this bug.