Mailinglist Archive: opensuse (1047 mails)

< Previous Next >
Re: [opensuse] Format disk with 13.2 btrfs file system
On 01/17/2016 01:06 PM, don fisher wrote:
What happens when you are left with an unbootable drive? With all other
systems I have used rsync to maintain a mirror of my primary host that I
can restore from a bootable media, such as a USB drive.

if you are talking about backup for restoration then that's an entirely
different thing, but there is STILL no necessity for BtrFS.

Its the files that count!


A main drive may be unbootable for a number of reasons.
The #1 is simply you have a dead (as in unrecoverable) drive.

If you're thinking of a DR scenario then make that clear and treat it as
such, which nothing you've written indicates that this is what's going
on. many of us here have in-depth knowledge of DR planning and tactics
and can advise you. If so, make that clear and ask.

What's *!*ESSENTIAL*!* for a recovery is

1. DATA
2. Configuration
3. Customizations

What is not essential is 'distribution code'.

I've done cost-benefit analysis for a variety of firms on
backup/recovery strategies for different scenarios. The ones running
traditional mainframes always had the kind of versioning that we now
have with snapshots did well when there was a "oops!" class mistake in
user files, and when they tested new releases of vendor code and needed
to roll-back. In DISASTER scenarios where the disk was lost the
snapshot were of no use as they too were on the disk. What mattered was
the off-machine backups.

One strategy for off machine backup is to backup the complete machine
image. Its advantage is that if you destroy the machine or disk you can
'restore everything' to the point of the last backup.

Oh, right, there's Schrodinger's Law of Backups.
"The condition of any backup is unknown until a backup is attempted".

Quite apart from that, such a strategy requires a strict discipline and
assumes that changes between, say, daily backups are not critical.
That may be true of code updates; yes you can re-run a zypper after
restoring yesterday's backup is restored to repeat the changes of today,
but DATA is another matter. See #1 above.

Oh, and I've also seem a business wiped out by an obsession with keeping
complete image backups. If you business requires, say, comparing this
months result for a client with the same month last year and the year
before, then extracting single files or parts from a backup that is
geared to imaging disks is awkward. Backups should follow business
strategy. You need to differentiate between backups and archives. Oh,
and some people switch around the meaning of those two terms.

I've lost bootability many times for a variety of reasons.
When its not been a dead disk I've *ALWAYS* been able to recover using
the 'repair' option on the distribution CD/DVD.

You might note that the DVD uses an ISO file system not a BtrFS.

You might also note that many of us backup using rsync to the cloud,
where we don't know what file system is being used.

Yes, there are going to be issues about the destination file system. It
needs to be able to handle pathnames as segment names and file names
that are as long as you are using. It needs to be sure that you don't
run out of inodes while there's plenty of data space available, which is
why I prefer backing up to ReiserFS than ext4FS.

But there is nothing that means you need to back up a BtrFS to a BtrFS
or that you need a BtrFS to restore it to. If that kind of symmetry
was needed we'd never be able to put the distribution on a DVD with an
ISOFS or make backups to an DVD.


--
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >