2016-03-23 23:31 GMT+01:00 Vytautas D <vyt...@gmail.com>:
>
>> atime). Also, this might break some configurations not expecting the
>> set-default method
>
> I have never seen this before. Can you extend on this or provide a link so i
> can read more about such limitation?
>>

Ubuntu, for instance. Layout as /@ for root FS and /@home for /home.
Set-default will break this.

>> >  2. reboot
>> > b) always mount into snapshot
>> >  1. mount -o suvol=/.current $disk # at initrd
>> >  2. btrfs subvol del /.current
>> >  3. btrfs subvol snapshot /.snapshotA /.current
>> >  4. reboot
>> > c) rsync
>> >  1. rsync $options /.snapshotA /.current
>> >  2. reboot
>>
>> Depending on how broken the setup is, I'd probably go for the btrfs
>> sub snap ./__snapshots/@oldsnap ./@current approach.
> Is there a technical reason behind this ?
>

I'm not sure I understand what "this" refers to, but another way to do
it would be to just move the snap and set it as rw. But that consumes
the snapshot for further use.


>> If it is very broken (as in not bootable), then a temporary boot into
>> a readonly snapshot might be required. This is quite easy to do in
>> the grub menu, changing the boot parameter. I've also heard of
>> symlinking to the actual subvolume you want to use, and resymlink it
>> when an older snapshot is desired.
>
> Just to make it clear, i don't have broken system and have full control. I
> am interested in strategies and reasoning.

What I meant was that there are different levels of "breaking".
Depending on how bad the failure is, a rollback on the live FS might
be sufficient.

mv @ @broken
btrfs sub snap __snap/@_$date @
reboot

>>
>> >
>> > - Vytas Dauksa
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
>> > in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to