On Monday, 07/24/2006 at 05:16 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote:
> No need to shut down any application. If a database has a file state
> at any point in time that it cannot recover from you are in deep
> problems anyway (think of power outage). Databases are supposed to be
> transactional. That also applies the the general case "application".
>
> The snapshot is atomic for all files of a file system like flashcopy
> or power outage, thus I expect the application and the filesystem to
> be able to recover from the copy. This applies only _if_ all files
> relevant to the application live on the same filesystem (which can
> span multiple dasds with lvm).
I guess it's just a risk/benefit thing. If you're like most people and do
not know (and do not *wish* to know) the implementation details of the
applications you run, then you have less risk to manage if you simply
bring down the server. Use application clusters to provide availability
if 100% up-time is required.
If you *do* know how the application is implemented and fully understand
the relationships of all the files, then you can build customized backup
strategies.
A little learning is a dangerous thing; drink deep,
or taste not the Pierian spring: there shallow draughts
intoxicate the brain, and drinking largely sobers us again.
- Alexander Pope, 1709
But rather than focus on that "edge" condition, we are all, I think, in
violent agreement that you cannot take a volume-by-volume physical backup
from outside a running Linux system and expect to have a usable backup.
Shared dasd on System z has all the same issues that shared LUNs have on
distributed systems. The backup *strategies* are identical, even if the
mechanisms used to create the backups are not.
Alan Altmark
z/VM Development
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
