[ale] Clone live system? (and other things)

[jonhall80 at comcast.net]

Storage size is not the only reason for splitting up the system file tree.  Access time to the data is another reason.

In "the old days" separating /tmp, swap and other "heavy I/O" areas of the disk from user files could improve throughput of some systems from 20-40%.   There were concepts of being "I/O bound" as well as cpu bound, particularly on devices like slow disk drives with head movement.

SSDs and larger memory buffers help to alleviate this issue, but even with SSDs you might find that one controller (say a USB) is "I/O bound".

Splitting up the file tree also allows for you to mount different filesystems in different ways.  If /tmp is really "temp files" then why would you use a log-based file system on it?  If the system crashes the easiest way of clearing it is to remake the file system.

[Note: It has been a long time since I had to look at this, so please take that into consideration.]

Along these lines, be aware that "cloning a live system" may allow for the cloned file system to be incomplete.  Depending on the cloning software and how tied it is to the actual operating system, file system buffers may not be copied properly, leaving data incomplete.

dd(1) is a good example of this.  If you are dd(1)ing a raw partition, it may not reach up into the file system buffer to copy that data to the new device....nor would dd(1) know how to apply that data.

Also long running user applications may not have flushed their data when their section of the disk is being copied.  Even if the filesystem structure is ok, the data of the application may be caught in an incomplete state.

As I said, it has been a long time since I had to think about this, but I will bring up these points for you "young-ins" to think about.

md




> On 07/17/2021 11:06 AM DJ-Pfulio via Ale <ale at ale.org> wrote:
> 
>  
> On 7/17/21 9:53 AM, Raj Wurttemberg via Ale wrote:
> > 
> > Now that COVID is slowly going away, some of our customers are now
> > looking to do some OS upgrades, mostly RHEL 6 to RHEL 8 and SuSE 12
> > to SuSE 15.  We have been using Relax and Recover (ReaR)
> > (https://access.redhat.com/solutions/2115051
> > <https://access.redhat.com/solutions/2115051>) which dumps the live
> > system to a bootable ISO. No outage is required.
> > 
> > We take the ISO, boot it on a temp server, upgrade the OS there and
> > on upgrade day, reverse the process on the day that we get an outage
> > from the customer. The ReaR process works ok, but if any of the file
> > systems are separated like /usr, or, /var, etc...  like you would
> > normally find on a system, ReaR runs into difficulties.
> > 
> > I did some Google-ing for other tools that can create a live clone of
> > a server. I did find two tools that look promising...
> > 
> > - doClone : http://doclone.nongnu.org/ <http://doclone.nongnu.org/> -
> > MondoRescue : http://www.mondorescue.org/
> > <http://www.mondorescue.org/>
> > 
> > Besides 'dd' I was curious what live cloning software you all have
> > tried.
> 
> Take an LVM snapshot and use fsarchiver on the snapshot.  Of course, if you don't have snapshot capable storage already, there isn't much that can be done.
> 
> The days of splitting off /usr have long ended. Heck, for lots of systems even /var/ doesn't need to be a separate FS. It isn't like our total storage is 200MB and log file sizes can't be limited.  
> 
> A quick analysis of the storage layout should easily tell an admin if they need multiple LVs for different storage areas.
> Handy: lsblk -e 7 -o name,size,type,fstype,mountpoint'
> 
> Add in the uuid column, if you mount using those. 
> I prefer using the /dev/{vg-name}/{lv-name} mount device links.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo