Re: fs snapshots
Alex Kicelew -> debian-russian@lists.debian.org @ Fri, 27 Oct 2017 16:44:13 +0300: >> Если я правильно помню документацию, там можно сделать ветку от >> снапшота, отредактировать ее и поменять ее со снапшотом местами. Но это >> мучительный и геморройный процесс. > Поменять местами с фс, на основании которой был сделан снапшот. > Насколько я понимаю, штатными средствами внести изменения в снапшот > невозможно. А нештатные могут вызвать приступ удивления с необратимыми > последствиями как у zfs, так и у юзера. Я точно уже не помню, но кажется, все же можно именно со снапшотом. В смысле, что изменения будут перекомпонованы. Другое дело, что по здравом размышлении, это в любом случае плохая идея. Если уж сделал снапшот, то нефиг его менять.
Re: fs snapshots
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
> 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
On 10/27/17 16:39, Artem Chuprina wrote: > Если я правильно помню документацию, там можно сделать ветку от > снапшота, отредактировать ее и поменять ее со снапшотом местами. Но это > мучительный и геморройный процесс. Поменять местами с фс, на основании которой был сделан снапшот. Насколько я понимаю, штатными средствами внести изменения в снапшот невозможно. А нештатные могут вызвать приступ удивления с необратимыми последствиями как у zfs, так и у юзера.
Re: fs snapshots
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
> Artem Chuprina writes: […] > P.S. Снапшоты эти новомодные тоже… Когда выясняется, что в старых > бэкапах много лишнего, а диск не резиновый, из бэкапов это вычистить > можно, а из снапшотов — увы. Только весь снапшот целиком, а это не > то, что нужно народу. Хотя, конечно, невозможность вычистить что-то > _случайно_ некоторую ценность имеет. Строго говоря, смысл создания (read-only) snapshot как раз в том, что с него удобно делать backup. Тем же Rsync. (Касаемо «невозможности» — рискну предположить, что здесь, скорее, «штатными средствами». Я могу себе представить инструмент для «пересборки» неактивной ФС.) Btrfs умеет btrfs-send(8) и -receive, что позволяет пересылать снимки на отдельную машину (с бо́льшим дисковым пространством) для хранения, но я так полагаю, необходимости «классического» backup оно не отменяет. PS. Так или иначе, представляется полезным держать /var/cache на отдельной ФС. (Не говоря уже о /home.) -- FSF associate member #7257