On 11/13/2015 12:59 PM, J Martin Rushton wrote:
Maybe I should have been clearer: use (LVM) OR (RAID1 and break).
I took your meaning. I'm saying that's a terrible backup strategy, for a list of reasons.
For instance, it only works if you mirror a single disk. It doesn't work if you use RAID10 or RAID5, or RAID6, or RAIDZ, etc. Breaking RAID doesn't make the data consistent, so you might have corrupt files (especially if the system runs any kind of database. SQL, LDAP, etc). It doesn't make the filesystem consistent, so you might have a corrupt filesystem.
Even if you ignore the potential for corruption, you have a backup process that only works on some specific hardware configurations. Everything else has to have a different backup solution. That's insane. Use one backup process that works for everything. You're much more likely to consistently back up your data that way.
I hope I'm wrong, but you wouldn't be thinking of mounting the broken out copy on a the same system would you? You must never do that, not even during disaster recovery. Use dd or similar on the disk, not the mounted partitions - isn't that obvious? I wasn't trying to give step by step instructions.
Well, that's *one* of the problems with your advice. Even if we ignore the fact that it doesn't work reliably (and IMO, it therefore doesn't work), it's far more complicated than you pretend it is.
Because now you're talking about quiescing your services, breaking your RAID, physically removing the drive, connecting it to another system, fsck the filesystems, mount them, and backing up the data. For each backup. Every day.
Or using 'dd' and... backing up the whole image? No incremental or differentials?
Your process involves a human being doing physical tasks as part of the backup. Maybe I'm the only one, but I want my backups fully automated. People make mistakes. I don't want them involved in regular processes. In fact, the entire point of computing is that the computer should do the work so that I don't have to.
Way before LVM existed we used this technique to back up VAXes (and later Alphas) under VMS using "volume shadowing" (ie RAID1). It worked quite happily for several years with disks shared across the cluster. IIRC it was actually recommended by DEC, indeed a selling point, but I don't have any manuals to hand to confirm that nowadays! One thing I did omit was you MUST sync first
sync flushes the OS data buffers to disk, but it does not sync application data buffers, it does not flush the journal, it doesn't make filesystems "clean", and even if you break the RAID volume immediately after "sync" there's no guarantee that there weren't cached writes from other processes in between those two steps.
There is absolutely no way to make this a reliable process without a full shutdown.
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
