Re: fs snapshots

2017-10-27 Пенетрантность Artem Chuprina 
Alex Kicelew -> debian-russian@lists.debian.org  @ Fri, 27 Oct 2017 16:44:13 
+0300:

 >> Если я правильно помню документацию, там можно сделать ветку от
 >> снапшота, отредактировать ее и поменять ее со снапшотом местами. Но это
 >> мучительный и геморройный процесс.

 > Поменять местами с фс, на основании которой был сделан снапшот.
 > Насколько я понимаю, штатными средствами внести изменения в снапшот
 > невозможно. А нештатные могут вызвать приступ удивления с необратимыми
 > последствиями как у zfs, так и у юзера.

Я точно уже не помню, но кажется, все же можно именно со снапшотом. В
смысле, что изменения будут перекомпонованы. Другое дело, что по здравом
размышлении, это в любом случае плохая идея. Если уж сделал снапшот, то
нефиг его менять.

Re: fs snapshots

2017-10-27 Пенетрантность Artem Chuprina 
Ivan Shmakov -> debian-russian@lists.debian.org  @ Fri, 27 Oct 2017 15:25:36 
+:

 >> Artem Chuprina  writes:
 >> Ivan Shmakov -> debian-russian@ @ Fri, 27 Oct 2017 12:30:45 +:
 >> Artem Chuprina  writes:

  P.S.  Снапшоты эти новомодные тоже…  Когда выясняется, что в старых
  бэкапах много лишнего, а диск не резиновый, из бэкапов это
  вычистить можно, а из снапшотов — увы.  Только весь снапшот
  целиком, а это не то, что нужно народу.  Хотя, конечно,
  невозможность вычистить что-то _случайно_ некоторую ценность имеет.

 >>> Строго говоря, смысл создания (read-only) snapshot как раз в том,
 >>> что с него удобно делать backup.  Тем же Rsync.

 >> В ZFS — нет.  Там смысл в том, чтобы при необходимости вернуться к
 >> этому состоянию.

 >  Разве эти возможности исключают друг друга?

Нет. Но цель ставилась такая, которую я изложил.

 >  Так или иначе, если при решении задачи данным средством
 >  возникает проблема, есть повод задуматься, а не следует ли
 >  поискать иные средства?

Да, разумеется. Это были скорее размышления вслух, нежели вопрос "как
чинить". У обоих подходов есть плюсы и минусы. Вернее, у всех трех,
потому что надо, однако, разделять понятия бэкапа и архива. Додумаю
мысль и сделаю как надо.

 >>> (Касаемо «невозможности» — рискну предположить, что здесь, скорее,
 >>> «штатными средствами».  Я могу себе представить инструмент для
 >>> «пересборки» неактивной ФС.)

 >> Если я правильно помню документацию, там можно сделать ветку от
 >> снапшота, отредактировать ее и поменять ее со снапшотом местами.
 >> Но это мучительный и геморройный процесс.

 >  Аналогично с Btrfs.  Единственная сложность — «меняемый местами»
 >  подтом (subvolume; он же в данном случае snapshot) не должен
 >  использоваться.  В остальном — подобно:

 > # btrfs subvolume snapshot -- .snapshot/foo .snapshot/foo-edit 
 > # # (меняем foo-edit) 
 > # btrfs subvolume snapshot -r -- .snapshot/foo-edit .snapshot/foo.new \
 >   && btrfs subvolume delete -- .snapshot/foo \
 >   && mv -nT -- .snapshot/foo.new .snapshot/foo 

 >  Другое дело, что при наличии более чем одного снимка с «тяжелым»
 >  содержимым, эти действия потребуется повторить для каждого.

Ну да, и в ZFS то же самое. И мысль в том, что оно же не просто так
такое сложное, а как бы намек, что так делать не надо. А надо или диск
побольше (что, кстати, наверное, более правильное решение, но пока жаба
душит), или все же делать изменяемые бэкапы.

Re: fs snapshots

2017-10-27 Пенетрантность Ivan Shmakov 
> Artem Chuprina  writes:
> Ivan Shmakov -> debian-russian@ @ Fri, 27 Oct 2017 12:30:45 +:
> Artem Chuprina  writes:

 >>> P.S.  Снапшоты эти новомодные тоже…  Когда выясняется, что в старых
 >>> бэкапах много лишнего, а диск не резиновый, из бэкапов это
 >>> вычистить можно, а из снапшотов — увы.  Только весь снапшот
 >>> целиком, а это не то, что нужно народу.  Хотя, конечно,
 >>> невозможность вычистить что-то _случайно_ некоторую ценность имеет.

 >> Строго говоря, смысл создания (read-only) snapshot как раз в том,
 >> что с него удобно делать backup.  Тем же Rsync.

 > В ZFS — нет.  Там смысл в том, чтобы при необходимости вернуться к
 > этому состоянию.

Разве эти возможности исключают друг друга?

Так или иначе, если при решении задачи данным средством
возникает проблема, есть повод задуматься, а не следует ли
поискать иные средства?

 >> (Касаемо «невозможности» — рискну предположить, что здесь, скорее,
 >> «штатными средствами».  Я могу себе представить инструмент для
 >> «пересборки» неактивной ФС.)

 > Если я правильно помню документацию, там можно сделать ветку от
 > снапшота, отредактировать ее и поменять ее со снапшотом местами.
 > Но это мучительный и геморройный процесс.

Аналогично с Btrfs.  Единственная сложность — «меняемый местами»
подтом (subvolume; он же в данном случае snapshot) не должен
использоваться.  В остальном — подобно:

# btrfs subvolume snapshot -- .snapshot/foo .snapshot/foo-edit 
# # (меняем foo-edit) 
# btrfs subvolume snapshot -r -- .snapshot/foo-edit .snapshot/foo.new \
  && btrfs subvolume delete -- .snapshot/foo \
  && mv -nT -- .snapshot/foo.new .snapshot/foo 

Другое дело, что при наличии более чем одного снимка с «тяжелым»
содержимым, эти действия потребуется повторить для каждого.

[…]

-- 
FSF associate member #7257

Re: fs snapshots

2017-10-27 Пенетрантность Alex Kicelew 
On 10/27/17 16:39, Artem Chuprina wrote:
> Если я правильно помню документацию, там можно сделать ветку от
> снапшота, отредактировать ее и поменять ее со снапшотом местами. Но это
> мучительный и геморройный процесс.

Поменять местами с фс, на основании которой был сделан снапшот.
Насколько я понимаю, штатными средствами внести изменения в снапшот
невозможно. А нештатные могут вызвать приступ удивления с необратимыми
последствиями как у zfs, так и у юзера.

Re: fs snapshots

2017-10-27 Пенетрантность Artem Chuprina 
Ivan Shmakov -> debian-russian@lists.debian.org  @ Fri, 27 Oct 2017 12:30:45 
+:

 >> Artem Chuprina  writes:

 > […]

 >> P.S.  Снапшоты эти новомодные тоже…  Когда выясняется, что в старых
 >> бэкапах много лишнего, а диск не резиновый, из бэкапов это вычистить
 >> можно, а из снапшотов — увы.  Только весь снапшот целиком, а это не
 >> то, что нужно народу.  Хотя, конечно, невозможность вычистить что-то
 >> _случайно_ некоторую ценность имеет.

 >  Строго говоря, смысл создания (read-only) snapshot как раз в
 >  том, что с него удобно делать backup.  Тем же Rsync.

В ZFS - нет. Там смысл в том, чтобы при необходимости вернуться к этому
состоянию.

 >  (Касаемо «невозможности» — рискну предположить, что здесь,
 >  скорее, «штатными средствами».  Я могу себе представить
 >  инструмент для «пересборки» неактивной ФС.)

Если я правильно помню документацию, там можно сделать ветку от
снапшота, отредактировать ее и поменять ее со снапшотом местами. Но это
мучительный и геморройный процесс.

 >  Btrfs умеет btrfs-send(8) и -receive, что позволяет пересылать
 >  снимки на отдельную машину (с бо́льшим дисковым пространством)
 >  для хранения, но я так полагаю, необходимости «классического»
 >  backup оно не отменяет.

 > PS.  Так или иначе, представляется полезным держать /var/cache на
 >  отдельной ФС.  (Не говоря уже о /home.)

Не, там не кэши. Это бэкапы юзерского контента с виндовой машины (читай:
даже home не весь, а выборочно). Просто в некоторый момент выясняется,
что некоторые директории очень немалого суммарного размера бэкапить не
надо (было). А диск не резиновый на бэкап-сервере.

fs snapshots

2017-10-27 Пенетрантность Ivan Shmakov 
> Artem Chuprina  writes:

[…]

 > P.S.  Снапшоты эти новомодные тоже…  Когда выясняется, что в старых
 > бэкапах много лишнего, а диск не резиновый, из бэкапов это вычистить
 > можно, а из снапшотов — увы.  Только весь снапшот целиком, а это не
 > то, что нужно народу.  Хотя, конечно, невозможность вычистить что-то
 > _случайно_ некоторую ценность имеет.

Строго говоря, смысл создания (read-only) snapshot как раз в
том, что с него удобно делать backup.  Тем же Rsync.

(Касаемо «невозможности» — рискну предположить, что здесь,
скорее, «штатными средствами».  Я могу себе представить
инструмент для «пересборки» неактивной ФС.)

Btrfs умеет btrfs-send(8) и -receive, что позволяет пересылать
снимки на отдельную машину (с бо́льшим дисковым пространством)
для хранения, но я так полагаю, необходимости «классического»
backup оно не отменяет.

PS.  Так или иначе, представляется полезным держать /var/cache на
отдельной ФС.  (Не говоря уже о /home.)

-- 
FSF associate member #7257