date:20120527

27.05.2012 02:08, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 00:23:43
+0400:

может подойти rsnapshot
последний месяц или чтото - более частые , сливающиеся в более редкие.

на основе rsync я и самописно делал инкрементальную бекапилку.
но rsnapshot таки получше будет.
АН О, я смотрел про него. Но как-то не оценил. А какие у него преимущества?
АН И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап является, в
АН принципе, полным, только файлы не копируются, а создаются ссылки?
АН Хм... Т.е., сжатие там никак не сделать?

Сжатая файловая система? Во всяком случае, вариант шифрованного
обратно-инкрементального бэкапа я сделал именно по этому пути.
Т.е. бэкап делать в файл, который монтировать, как loop?

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

Когда мне хотелось шифровать бэкап gpg (для нескольких ключей), с
невозможностью для автоматики бэкап-сервера расшифровать предыдущий
бэкап, я делал инкременталку таром.
А как это реализовано? Шифровался только уже неиспользуемый бэкап или как-то
менялись ключи?
Насчёт тара: инкрементальный бэкап вы делали без полного копирования предыдущего
и применения tar -g, затем (с копированием в статье было сделано)?

P.S.:
Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc1cbd7@yandex.ru

Re: Вопросы про бэкапы.

Про прямые и обратные бэкапы уже ответили в сообщении позже. Не посмотрел. :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc1cd07.1080...@yandex.ru

Re: Вопросы про бэкапы.

P.S.:
Читаю. Ниже написали, что rsnapshot такое же может.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc1cf34.9070...@yandex.ru

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Mikhail A Antonov

Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 10:38:15 +0400:

может подойти rsnapshot
последний месяц или чтото - более частые , сливающиеся в более редкие.

на основе rsync я и самописно делал инкрементальную бекапилку.
но rsnapshot таки получше будет.
АН О, я смотрел про него. Но как-то не оценил. А какие у него
преимущества?
АН И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап является,
в
АН принципе, полным, только файлы не копируются, а создаются ссылки?
АН Хм... Т.е., сжатие там никак не сделать?

http://code.google.com/p/fusecompress/. Сам, правда, не пользовался, врать не
буду.

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

Прямо-инкрементальный - это как делает большинство бэкапных утилит:
берется полный в какой-то момент, и дальше бэкапятся только те файлы,
которые изменились с предыдущего бэкапа.

Обратно-инкрементальный - это когда у тебя хранится в качестве полного
последняя копия, а предыдущие (на случай, если захочется восстановить
файл, удаленный по ошибке месяц назад) хранятся как разница между собой
и следующим. Ну, в случае rsnapshot они все хранятся как полные, только
используются хардлинки на совпадающие файлы.

Бэкап шифровался на лету, pgp умеет шифровать поток. Бэкап-сервер
получал уже зашифрованный бэкап. Зашифрованный, если вдруг не понято,
pgp - то есть так, что расшифровать могут только те люди, которые были
предусмотрены в момент шифрования. Бэкап-сервер таким человеком (и
вообще человеком) не является, и расшифровать бэкап поэтому не может.
Поэтому компрометация бэкап-сервера не приводит к компрометации
хранящихся на нем бэкапов.

АН Насчёт тара: инкрементальный бэкап вы делали без полного копирования
предыдущего
АН и применения tar -g, затем (с копированием в статье было сделано)?

Типа того. Короче, штатными средствами, описанными в info tar. (Я,
прежде чем применить написанное на заборе, обычно лезу в штатную
документацию.)

АН P.S.:
АН Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.

Кстати, к вопросу о сжатии. LUKS заодно сжимать не умеет? Для задач
шифрования это вообще довольно типичное умение - поскольку задача
шифрования сама по себе ресурсоемкая, добавить туда предварительное
сжатие обычно не только не жалко, но и может повысить
производительность.

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Sergej Kochnev

On Sun, 27 May 2012 11:15:06 +0400
Artem Chuprina r...@ran.pp.ru wrote:

Кстати, к вопросу о сжатии.  LUKS заодно сжимать не умеет?  Для задач
шифрования это вообще довольно типичное умение - поскольку задача
шифрования сама по себе ресурсоемкая, добавить туда предварительное
сжатие обычно не только не жалко, но и может повысить
производительность.

Нет, не умеет.


pgpmGe5rZz6Gn.pgp
Description: PGP signature

Re: Что-то сломал в кедах. Теперь нет звука совершенно.

2012-05-27 Пенетрантность dimas

со speaker-test поиграйся. можно в tty, без запуска иксов с кедами. может, не в 
одних гуях сломалось


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527124116.0d634...@ulf.tvoe.tv

Re: Вопросы про бэкапы.

27.05.2012 10:38, Артём Н. пишет:
 Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
Если в момент когда фс примонтирована будет скомпрометирован
бэкап-сервер - LUKS тебе не поможет. А вот зашифрованное gpg хоть на
папблик фтп клади. Или ты бэкапишь прямо раздел с фс? lvm, снапшот, dd.
Но там инкрементальным особо не поделаешь его.

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.pp.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: Вопросы про бэкапы.

может подойти rsnapshot
последний месяц или чтото - более частые , сливающиеся в более редкие.

на основе rsync я и самописно делал инкрементальную бекапилку.
но rsnapshot таки получше будет.
АН О, я смотрел про него. Но как-то не оценил. А какие у него
преимущества?
АН И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап
является, в
АН принципе, полным, только файлы не копируются, а создаются ссылки?
АН Хм... Т.е., сжатие там никак не сделать?

Сжатая файловая система? Во всяком случае, вариант шифрованного
обратно-инкрементального бэкапа я сделал именно по этому пути.
АН Т.е. бэкап делать в файл, который монтировать, как loop?
http://code.google.com/p/fusecompress/. Сам, правда, не пользовался, врать
не буду.
Сжимать всё? А сжимать один бэкап..?
Ну, т.е. сжимать каждый из дневных бэкапов не имеет смысла: изменений мало, а
производительность, при полном сжатии, уменьшается.
Достаточно сжать бэкап за месяц. Но, при этом, как я понял, не будут работать
инкрементальные бэкапы?

Прямо-инкрементальный лучше делать таром, он все необходимое умеет.
АН Ээ... А возможно подробнее: что такое обратно-инкрементальный и
АН прямо-инкрементальный?
Прямо-инкрементальный - это как делает большинство бэкапных утилит:
берется полный в какой-то момент, и дальше бэкапятся только те файлы,
которые изменились с предыдущего бэкапа.
Обратно-инкрементальный - это когда у тебя хранится в качестве полного
последняя копия, а предыдущие (на случай, если захочется восстановить
файл, удаленный по ошибке месяц назад) хранятся как разница между собой
и следующим. Ну, в случае rsnapshot они все хранятся как полные, только
используются хардлинки на совпадающие файлы.
Ага, понятно. Хм... Это делает rsnapshot или rsync? И есть ли какие-то побочные
эффекты от большого количества хардлинков (ведь придётся в каждом новом бэкапе
создавать ссылку на каждый не изменённый файл старого)?

Прямо-инкрементальный лучше обратно-инкрементального тем, что для
создания следующей копии не требуется доступ к предыдущей, достаточно
знать момент ее создания. А хуже тем, что для восстановления последней
версии (а обычно нужно восстановить именно ее) приходится накатывать всю
последовательность, начиная с полного бэкапа.
Смотрю в сторону rdiff-backup и rsnapshot или rsync (склоняюсь к первому).
Но у обратных бэкапов минус: я не могу сжать полный бэкап.
Потому что изменения вносятся в него.
Хм... Да и в случае прямого мне не очень понятно... Например, сжал я полный
бэкап. Но ведь Его надо распаковывать, чтобы сравнивать, что изменилось?
Или должен быть файл с метаинформацией, как в случае с tar?

В любом случае, как я понимаю, у обратных бэкапов сжимать полный бэкап
возможности нет?

Типа того. Короче, штатными средствами, описанными в info tar. (Я,
прежде чем применить написанное на заборе, обычно лезу в штатную
документацию.)
Да я читал. Всё-равно непонятно возможно ли как-то сливать бэкапы в один (без
особых сложностей).

АН P.S.:
АН Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
Кстати, к вопросу о сжатии. LUKS заодно сжимать не умеет? Для задач
шифрования это вообще довольно типичное умение - поскольку задача
шифрования сама по себе ресурсоемкая, добавить туда предварительное
сжатие обычно не только не жалко, но и может повысить
производительность.
Не, LUKS - это Linux Unified Key System. Только шифрование. К тому же, поверх
него ещё ФС (а может и LVM - я уж не помню точно как там у меня сделано).
К тому же, сжатие всей ФС мне не очень нужно.

P.S.:
А вы о dar можете что-нибудь сказать?

Re: Вопросы про бэкапы.

27.05.2012 13:41, Mikhail A Antonov пишет:
27.05.2012 10:38, Артём Н. пишет:
Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
Если в момент когда фс примонтирована будет скомпрометирован
бэкап-сервер - LUKS тебе не поможет. А вот зашифрованное gpg хоть на
папблик фтп клади.
Понимаю. Но backup сервером является мой комп, за которым я и сижу. Только диски
отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт (давно
такого не было, но всё-таки).
Так что, если он будет скомпрометирован, бэкап защищать уже не придётся. :-)
Просто мне спокойнее, когда на диске все потенциально чувствительные данные
шифруются.

Или ты бэкапишь прямо раздел с фс? lvm, снапшот, dd.
Но там инкрементальным особо не поделаешь его.
Нет. Я хочу бэкапить:
1. Выбранные каталоги системы (/etc, /var/lib, например).
2. Настройки системы (к примеру, конфиг ядра, который меняется, БД, dpkg
--get-selections).
3. Выбранные пользовательские каталоги.

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Mikhail A Antonov

27.05.2012 01:59, alex kuklin пишет:
 А не overkill?  А почему?


 потому что умеет
 - дедупликацию файлов
 - гибкое хранение копий (первую неделю все, потом через день, потом через 
 неделю
 и т.п.)
 - умеет разные методы доступа к файлам
 - достаточно легкий и простой в развертывании
BackupPC на будущее отмечу. В принципе, он достаточно приятный на вид и по
описанию. И, похоже, удобный.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc1fa81.5010...@yandex.ru

Re: Вопросы про бэкапы.

27.05.2012 13:54, Артём Н. пишет:
27.05.2012 13:41, Mikhail A Antonov пишет:
27.05.2012 10:38, Артём Н. пишет:
Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
Если в момент когда фс примонтирована будет скомпрометирован
бэкап-сервер - LUKS тебе не поможет. А вот зашифрованное gpg хоть на
папблик фтп клади.
Понимаю. Но backup сервером является мой комп, за которым я и сижу. Только
диски
отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт (давно
такого не было, но всё-таки).
Так что, если он будет скомпрометирован, бэкап защищать уже не придётся. :-)
Просто мне спокойнее, когда на диске все потенциально чувствительные данные
шифруются.
Я посмотрю на твой бэкап когда у тебя БП сожжёт диски после скачка
напряжения.
Ну или когда оба (или сколько там их) диска головами плюхнутся на блины,
всё от того же скачка.
Домашние ИБП даалеко не все скачки пережевать могут.

--
Best regards,
Mikhail
-
WWW: http://www.antmix.pp.ru/
XMPP: ant...@stopicq.ru

signature.asc
Description: OpenPGP digital signature

Re: Вопросы про бэкапы.

27.05.2012 14:07, Mikhail A Antonov пишет:
27.05.2012 13:54, Артём Н. пишет:
27.05.2012 13:41, Mikhail A Antonov пишет:
27.05.2012 10:38, Артём Н. пишет:
Внешнее шифрование мне не требуется: у меня бэкап ФС над LUKS.
Если в момент когда фс примонтирована будет скомпрометирован
бэкап-сервер - LUKS тебе не поможет. А вот зашифрованное gpg хоть на
папблик фтп клади.
Понимаю. Но backup сервером является мой комп, за которым я и сижу. Только
диски
отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт (давно
такого не было, но всё-таки).
Так что, если он будет скомпрометирован, бэкап защищать уже не придётся. :-)
Просто мне спокойнее, когда на диске все потенциально чувствительные данные
шифруются.
Я посмотрю на твой бэкап когда у тебя БП сожжёт диски после скачка
напряжения.
Ну так, мне и бэкап-сервер не поможет, если, конечно, это не облачный бэкап
(но у него свои недостатки). :-)

Ну или когда оба (или сколько там их) диска головами плюхнутся на блины,
всё от того же скачка.
Домашние ИБП даалеко не все скачки пережевать могут.
Думаю, вероятность того примерно такая же, как у стихийного бедствия. А от
поломки диска - защитит.

Re: Вопросы про бэкапы.

27.05.2012 14:07, Mikhail A Antonov пишет:
 Понимаю. Но backup сервером является мой комп, за которым я и сижу. Только 
 диски
 отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт (давно
 такого не было, но всё-таки).
 Так что, если он будет скомпрометирован, бэкап защищать уже не придётся. :-)
 Просто мне спокойнее, когда на диске все потенциально чувствительные данные
 шифруются.
 Я посмотрю на твой бэкап когда у тебя БП сожжёт диски после скачка
 напряжения.
Хотя, конечно, возможно делать бэкап, например, на ноут. Но опять же: гонять
данные по сети (даже несмотря на инкрементальные бэкапы, ведь он подключен по
wi-fi), настраивать всё на ноуте, держать его включённым...
Ради чего, у меня не такие серьёзные данные?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc1ff20.1070...@yandex.ru

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность -=Devil_InSide=-

27.05.2012 01:05, Dmitry Nezhevenko пишет:
Для личных целях пользуюсь rdiff-backup. Это похоже что единственная
софтинка, у которой инкрементальные бэкапы сделаны в обратную сторону.
Т.е. последнее состояние хранится в виде точной копии FS (соответственно
можно смотреть без всяких спец. утилит), а инкрементальные бэкапы --
информация как получить предыдущую копию из текущей.
Почитал. Так и не понял: возможно ли штатными средствами делать слияния бэкапов?
В теории возможно написать скрипт для слияния, т.к. формат достаточно прост.
Но стоит ли оно того?
rsnapshot мне показался прозрачнее (в плане хранения бэкапов). Да и, к тому же,
я могу восстановить любую версию без слияния (благодаря жёстким ссылкам всегда
доступна полная версия на любую точку бэкапа).
Плюс r-b - пишут, что она кроссплатформенная (хотя, вроде как, это скрипт на
питоне).
Но rsnapshot, вроде, тоже (по крайней мере, есть cygwin, если что).
И ещё rsnapshot написан на Perl, как я понял. Маааленький плюс, поскольку Python
я не знаю вообще, а Perl я не знаю меньше, чем вообще.
Слияния же с rsnapshot я могу делать простым копированием (в чём не уверен,
поскольку, возможно потребуется проверка на совпадение номеров inode во время
копирования).

Re: Вопросы про бэкапы.

,-[Артём Н., 27 May 2012 00:29]:

 26.05.2012 23:42, -=Devil_InSide=- пишет:
 на основе rsync я и самописно делал инкрементальную бекапилку.
 но rsnapshot таки получше будет.
 Да, и в принципе, здесь понятно как делать слияние: достаточно выполнить
 копирование последнего дневного бэкапа в недельный, а недельного в бэкап
 за месяц. Но:
 1. Ведь тоже самое я могу сделать и с rsync? Что мне даст дополнительный
 скрипт, её использующий?
удобство конфигурирования и отсутствие ломания головы.

 2. Использование хардлинков - это фича rsync или скрипта?
rsync

 3. Как сюда возможно прикрутить сжатие?
не знаю, у меня такой задачи не стояло.
)
 

-- 
__
mpd status: [paused]
Hellraiser - Killed By Death (Motorhead cov
**
*  jabber:  devil_ins...@jabber.ru   *
*   Registered linux user #450844*
**



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jpt4f0$lvb$1...@dough.gmane.org

Вопросы про бэкапы.

2012-05-27 Пенетрантность Павел Марченко

26 мая 2012 г., 21:43 пользователь Артём Н. artio...@yandex.ru написал:
Разбираюсь с бэкапами. Хочу сохранять свои файлы и состояние системы (/etc,
dpkg
--get-selections, базу) на отдельный диск.

Почитал и решил, что разумно было бы делать инкрементальные бэкапы каждый день
(отличия от предыдущего дня).
И ещё иметь один полный бэкап - всё за месяц. И один дифференциальный от него
за
1-4 недели после него.
Каждое воскресенье, например, все инкрементальные дневные бэкапы будут
сливаться
в один недельный.
В конце каждого месяца недельный бэкап будет сливаться с бэкапом за месяц.

Помимо прочего, хочется разобраться, как же они правильно делаются.

Вопросы:
1. Какие инструменты для создания бэкапов на локальном компьютере или для
небольшой локалки используются?
2. Я остановился на tar, dar и rsync.
С dar ещё не разбирался.
По tar прочитал статью. Там используется опция -g. Предыдущий бэкап
копируется,
затем tar из копии делает инкрементальный бэкап, используя -g и файл
метаданных.
С tar мне не понравилось копирование. Думаю, возможно с помощью пайпов его
избежать.

Но как слить вместе два бэкапа я не нашёл.
Возможно ли это и как?

По rsync читаю это (размер man по нему - убийственный):
http://www.mikerubel.org/computers/rsync_snapshots/
http://rsync.samba.org/examples.html

Пока не дочитал. Но хочется узнать заранее: есть ли у неё возможность сливать
бэкапы в один? И сложно ли к ней прикрутить сжатие?

Кто-нибудь пользовался dar? И что про него возможно сказать?

3. Кто как делает бэкапы, на практике?

P.S.:
В этих ваших гуглах смотрел. Информации много, но всё какое-то разрозненное...
На все вопросы, всё-равно не нашёл ответов. Если кто кинет ссылку на хорошую
статью, буду благодарен.

Вставлю и свои 5 копеек, на мой взгляд под задачу подходит
Bacula(http://www.bacula.org/en/). Есть в дистрибутиве. По началу
кажется очень сложной в настройке, но прочитав доку - все просто.
Делать слияние бэкапов не нужно, бэкала все задачи хранит в мускульной
базе и сама знает какой полный или диффиренциальный бэкап последний и
на основании этого троятся задачи.
пример конфига:
Client {
Name = webserv-fd
Address = 192.168.16.251
FDPort = 9102
Catalog = MainNode
Password = pass # password for FileDaemon
File Retention = 14 days
Job Retention = 14 days
AutoPrune = yes
}
Pool {
Name = Webserv
Pool Type = Backup
Recycle = yes # Bacula can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Maximum Volume Jobs = 7
Volume Retention = 21 days # 3 weeks
Maximum Volume Bytes = 10G # Limit Volume size to something
reasonable
Maximum Volumes = 4 # Limit number of Volumes in Pool
LabelFormat = web
}

Job {
Name = webserv
Type = Backup
Level = Incremental
Client = webserv-fd
FileSet = webserv
Schedule = WeeklyCycle
ClientRunBeforeJob = /etc/bacula/scripts/bk-mysql.sh #Do a MYSQL
dump before job and include it into job
ClientRunAfterJob = /bin/rm -rf /tmp/dump.sql
Storage = kiev
Messages = Daemon
Pool = Webserv
Priority = 10
Write Bootstrap = /var/lib/bacula/%c.bsr
}
FileSet {
Name = webserv
Include {
Options {
signature = MD5
compression = GZIP
wildfile = *.tar.gz*
}
File = /etc
File = /var/www/bitrix
File = /var/www/helpdesk
File = /tmp/dump.sql
}
}

Schedule {
Name = WeeklyCycle
Run = Full sun at 23:05
Run = Incremental mon-sat at 22:45
}

P.S. ссори за письмо в личку

--
В смысле осмысления бессмысленного смысл тоже имеет определенную
осмысленность!!!

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Dmitry Nezhevenko

On Sun, May 27, 2012 at 03:37:31PM +0400, Артём Н. wrote:
27.05.2012 01:05, Dmitry Nezhevenko пишет:
Для личных целях пользуюсь rdiff-backup. Это похоже что единственная
софтинка, у которой инкрементальные бэкапы сделаны в обратную сторону.
Т.е. последнее состояние хранится в виде точной копии FS (соответственно
можно смотреть без всяких спец. утилит), а инкрементальные бэкапы --
информация как получить предыдущую копию из текущей.
Почитал. Так и не понял: возможно ли штатными средствами делать слияния
бэкапов?
В теории возможно написать скрипт для слияния, т.к. формат достаточно прост.
Но стоит ли оно того?

Слияние ему не нужно вообще, ибо полный бэкап может один (последний). Он
умеет удалять старые бэкапы одной командой.

rsnapshot мне показался прозрачнее (в плане хранения бэкапов).

Да. Тут полностью согласен

Да и, к тому же,
я могу восстановить любую версию без слияния (благодаря жёстким ссылкам всегда
доступна полная версия на любую точку бэкапа).

Для rdiff_backup, чтобы восстановить непоследнюю версию, нужно либо
понимать его cli интерфейс либо использовать специальную FUSE файловую
систему.

Плюс r-b - пишут, что она кроссплатформенная (хотя, вроде как, это скрипт на
питоне).

Да. И кроссплатформенность работает.

Но rsnapshot, вроде, тоже (по крайней мере, есть cygwin, если что).

Вряд-ли. rsnapshot использует хардлинки. Не факт что cygwin их умеет
правильно эмулировать.

--
WBR, Dmitry

signature.asc
Description: Digital signature

Re: Вопросы про бэкапы.

Павел Марченко - debian-russian  @ Sun, 27 May 2012 15:51:47 +0300:

 ПМ Вставлю и свои 5 копеек, на мой взгляд под задачу подходит
 ПМ Bacula(http://www.bacula.org/en/). Есть в дистрибутиве. По началу
 ПМ кажется очень сложной в настройке, но прочитав доку - все просто. 
 ПМ Делать слияние бэкапов не нужно, бэкала все задачи хранит в мускульной
 ПМ базе и сама знает какой полный или диффиренциальный бэкап последний и
 ПМ на основании этого троятся задачи.

Вообще идея хранить бэкапную информацию в mysql'ной базе сама по себе,
гм, смущает.  Учитывая, что тем, кто пользуется мысклем, чаще всего из
бэкапов приходится доставать именно его базы.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hav1ofc2@wizzle.ran.pp.ru

Re: Вопросы про бэкапы.

Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 14:17:04 +0400:

Понимаю. Но backup сервером является мой комп, за которым я и сижу. Только
диски
отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт (давно
такого не было, но всё-таки).
Так что, если он будет скомпрометирован, бэкап защищать уже не придётся.
:-)
Просто мне спокойнее, когда на диске все потенциально чувствительные данные
шифруются.
Я посмотрю на твой бэкап когда у тебя БП сожжёт диски после скачка
напряжения.
АН Хотя, конечно, возможно делать бэкап, например, на ноут. Но опять же:
гонять
АН данные по сети (даже несмотря на инкрементальные бэкапы, ведь он подключен
по
АН wi-fi), настраивать всё на ноуте, держать его включённым...
АН Ради чего, у меня не такие серьёзные данные?

Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
либо не достойны - и тогда их не надо бэкапить вообще. А _делать вид_,
что бэкапишь - это как-то странно...

Вообще первая аксиома бэкапа - достаточно свежая резервная копия данных
должна находиться на носителе, физически отключенном от основной копии и
желательно географически отдаленном. Для домашнего бэкапа иногда можно
пренебречь идеей, что такое должно выполняться в абсолютно любой момент
(и иметь один съемный бэкапный винчестер, а не минимум два), и хранить
копию в той же квартире. Но хранить ее подключенной к тому же
контроллеру - не очень умное действие.

Я в итоге для домашнего использования пользуюсь USB-винчестером (одним),
и бэкап запускаю вручную, подключив этот винчестер. И отключаю сразу
после того, как он завершился.

На прошлой работе, где я занимался бэкапами, бэкапы делались
автоматически, но в использовании было 5 сменных дисков, тоже USB, и
алгоритм их ротации, в соответствии с которым по крайней мере один в
любой момент находился вне офиса - либо у зам. генерального, либо у
админа дома. Вообще в любой момент. И копия на оном винте была,
соответственно, не старше двух рабочих дней.

Re: Вопросы про бэкапы.

On Sun, May 27, 2012 at 06:51:13PM +0400, Artem Chuprina wrote:
 Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
 либо не достойны - и тогда их не надо бэкапить вообще. 
Чушь.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Andy

В Вск, 27/05/2012 в 20:56 +0600, Andrey Rahmatullin пишет:
 On Sun, May 27, 2012 at 06:51:13PM +0400, Artem Chuprina wrote:
  Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
  либо не достойны - и тогда их не надо бэкапить вообще. 
 Чушь.
Аргументируйте.

-- 
WBR, Abba.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1338125410.1942.0.camel@skynet

Re: Вопросы про бэкапы.

On Sun, May 27, 2012 at 04:30:10PM +0300, Andy wrote:
   Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
   либо не достойны - и тогда их не надо бэкапить вообще. 
  Чушь.
 Аргументируйте.
Пусть Чуприна аргументирует.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Вопросы про бэкапы.

Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 13:50:08 +0400:

может подойти rsnapshot
последний месяц или чтото - более частые , сливающиеся в более
редкие.

на основе rsync я и самописно делал инкрементальную бекапилку.
но rsnapshot таки получше будет.
АН О, я смотрел про него. Но как-то не оценил. А какие у него
преимущества?
АН И как он жёсткие ссылки использует? Т.е., каждый инкр. бэкап
является, в
АН принципе, полным, только файлы не копируются, а создаются ссылки?
АН Хм... Т.е., сжатие там никак не сделать?

Сжатая файловая система? Во всяком случае, вариант шифрованного
обратно-инкрементального бэкапа я сделал именно по этому пути.
АН Т.е. бэкап делать в файл, который монтировать, как loop?
http://code.google.com/p/fusecompress/. Сам, правда, не пользовался, врать
не буду.
АН Сжимать всё? А сжимать один бэкап..?
АН Ну, т.е. сжимать каждый из дневных бэкапов не имеет смысла: изменений
мало, а
АН производительность, при полном сжатии, уменьшается.

Расслабься, в _этом_ месте вопрос производительности не стоит. Особенно
- по сравнению с шифрованием.

АН Достаточно сжать бэкап за месяц. Но, при этом, как я понял, не
АН будут работать инкрементальные бэкапы?

Прямо-инкрементальные - будут, им доступ к этому бэкапу не нужен.

Прямо-инкрементальный лучше делать таром, он все необходимое умеет.
АН Ээ... А возможно подробнее: что такое обратно-инкрементальный и
АН прямо-инкрементальный?
Прямо-инкрементальный - это как делает большинство бэкапных утилит:
берется полный в какой-то момент, и дальше бэкапятся только те файлы,
которые изменились с предыдущего бэкапа.
Обратно-инкрементальный - это когда у тебя хранится в качестве полного
последняя копия, а предыдущие (на случай, если захочется восстановить
файл, удаленный по ошибке месяц назад) хранятся как разница между собой
и следующим. Ну, в случае rsnapshot они все хранятся как полные, только
используются хардлинки на совпадающие файлы.
АН Ага, понятно. Хм... Это делает rsnapshot или rsync?

rsnapshot перед запуском rsync. Делает cp -al (на не-линуксах эмулирует).

АН И есть ли какие-то побочные эффекты от большого количества
АН хардлинков (ведь придётся в каждом новом бэкапе создавать ссылку на
АН каждый не изменённый файл старого)?

Нет. Они же хардлинки, от них даже количество инодов не пухнет. Иноды,
правда, кушаются директориями, которые при таком копировании таки
создаются.

Прямо-инкрементальный лучше обратно-инкрементального тем, что для
создания следующей копии не требуется доступ к предыдущей, достаточно
знать момент ее создания. А хуже тем, что для восстановления последней
версии (а обычно нужно восстановить именно ее) приходится накатывать всю
последовательность, начиная с полного бэкапа.
АН Смотрю в сторону rdiff-backup и rsnapshot или rsync (склоняюсь к первому).
АН Но у обратных бэкапов минус: я не могу сжать полный бэкап.
АН Потому что изменения вносятся в него.
АН Хм... Да и в случае прямого мне не очень понятно... Например, сжал я полный
АН бэкап. Но ведь Его надо распаковывать, чтобы сравнивать, что изменилось?
АН Или должен быть файл с метаинформацией, как в случае с tar?

Его нужно распаковывать не столько для того, чтобы сравнить, сколько для
того, чтобы поменять. Ведь принцип обратно-инкрементального бэкапа в
том, что полной хранится последняя версия.

АН В любом случае, как я понимаю, у обратных бэкапов сжимать полный бэкап
АН возможности нет?

В принципе - есть. В принципе ничто не мешает полный бэкап, сжатый хоть
тем же .tar.gz, прямо в пайпе разжать, поменять, что нужно, и положить
на диск. Однопроходного чтения _в принципе_ достаточно, поэтому место
нужно только для двух сжатых - старого и нового (ну и отдельно для
изменений, при сем образовавшихся). А вот есть ли для этого готовые
инструменты, я сомневаюсь.

В том случае мы в итоге делали полные, чтобы не морочиться с
инкрементальными при ротации дисков, но прямо-инкрементальным он может
быть с легкостью. Сервер еще и запускал процесс - заходил по ssh на
бэкапимый линукс, запускал там команду бэкапа (по этому ssh-ключу было
разрешено запустить только эту команду), и прямо в это же ssh-соединение
получал уже зашифрованный бэкап, который тупым cat'ом клал себе на диск.

С виндой было хуже, винда делала бэкап своим встроенным бэкапом (ага,
надо было бэкапить отнюдь не только файлы, а и Active Directory),

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Иван Лох

On Sun, May 27, 2012 at 06:51:13PM +0400, Artem Chuprina wrote:
 
 Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
 либо не достойны - и тогда их не надо бэкапить вообще.  А _делать вид_,
 что бэкапишь - это как-то странно...

Кстати, глубокая мысль. Только, на мой взгляд, есть два но. Во-первых,
то, что стоит бэкапить лучше положить в DVCS. Во-вторых, есть статика,
сотни гигабайт фотографии, например. Полноценный бэкап для них просто не 
нужен, зато нужна какая-то интеграция с облачными сервисами.


-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527151232.ga30...@nano.ioffe.rssi.ru

Re: Вопросы про бэкапы.

27.05.2012 17:30, Andy пишет:
В Вск, 27/05/2012 в 20:56 +0600, Andrey Rahmatullin пишет:
On Sun, May 27, 2012 at 06:51:13PM +0400, Artem Chuprina wrote:
Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
либо не достойны - и тогда их не надо бэкапить вообще.
Чушь.
Аргументируйте.
Я аргументирую.
1. Довольно странное утверждение, смахивает на проявление максимализма.
2. Данные имеют стоимость (оценка может быть формальной или субъективной, не
важно). Пример: для владельца архив фото из Ебипета имеет определённую цену.
3. Бэкап также имеет стоимость. Чем меньше вероятность потери данных,
защищённость и прочее, тем выше стоимость (как правило, поскольку могут
изменяться носители, может изменяться политика, при определённых объёмах,
множество причин есть).
4. Если стоимость бэкапа превышает стоимость данных, необходимости в таком
бэкапе нет.
Пример: фотографии достаточно залить на флешку, но делать для них систему бэкапа
(даже, если они меняются) - неразумно. Слишком сложно и не стоит того.
5. Имеется возможность восстановления данных. И вероятность неудачного
восстановления. Если носитель позволяет восстановить данные за стоимость меньшую
стоимости процесса бэкапа и стоимость данных с учётом вероятности невозможности
восстановления меньше стоимости бэкапа, вероятно необходимости в бэкапе также
нет.

Примерно так.

Нет данных достойных бэкапа. Есть дорогие и дешёвые данные, в определённых
условиях. По-моему, это очевидно...

Данные из датацентра, представляющие план развития подразделения крупной
корпорации, которые собирали, готовили и рассчитывали множество специалистов
стоят гораздо дороже, чем фотографии (хотя для владельца фотографий, вряд ли они
чего-то стоят, поскольку, скорее всего, он не сможет их использовать, но это
лирическое отступление). Они требуют сложной географически распределённой
системы бэкапов с резервированием, поскольку порядок убытков при потере
несоизмерим со стоимостью бэкапа.
Но это не значит, что фотографии ничего не стоят (ну представьте, что вы
потеряете, например, семейный фотоальбом, стоит ли он бэкапа?).
Просто их нужно бэкапить по-другому. Бэкап лишь снижает вероятность потери
данных за определённую цену.

Re: Вопросы про бэкапы.

27.05.2012 18:51, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 14:17:04
+0400:

Понимаю. Но backup сервером является мой комп, за которым я и сижу.
Только диски
отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт
(давно
такого не было, но всё-таки).
Так что, если он будет скомпрометирован, бэкап защищать уже не придётся.
:-)
Просто мне спокойнее, когда на диске все потенциально чувствительные
данные
шифруются.
Я посмотрю на твой бэкап когда у тебя БП сожжёт диски после скачка
напряжения.
АН Хотя, конечно, возможно делать бэкап, например, на ноут. Но опять же:
гонять
АН данные по сети (даже несмотря на инкрементальные бэкапы, ведь он
подключен по
АН wi-fi), настраивать всё на ноуте, держать его включённым...
АН Ради чего, у меня не такие серьёзные данные?

Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
либо не достойны - и тогда их не надо бэкапить вообще. А _делать вид_,
что бэкапишь - это как-то странно...
С чего вы взяли, что я делаю вид?
Я создаю дубликат нужных мне данных на отдельном диске.
Это снижает вероятность потери.

Вообще первая аксиома бэкапа - достаточно свежая резервная копия данных
должна находиться на носителе, физически отключенном от основной копии и
желательно географически отдаленном.
Второе - слишком дорого и того не стоит.
Физически диски разделены. Поскольку бэкап создаётся автоматически смысла в
отключении мало, а покупать ещё один диск - это накладно.

Для домашнего бэкапа иногда можно
пренебречь идеей, что такое должно выполняться в абсолютно любой момент
(и иметь один съемный бэкапный винчестер, а не минимум два), и хранить
копию в той же квартире. Но хранить ее подключенной к тому же
контроллеру - не очень умное действие.
Во-первых, второй диск внутренний.
Во-вторых, пока мне такое не требуется и одного постоянно подключенного диска
хватит. Если в будущем мои данные я оценю дороже, я приобрету внешний винчестер,
на который буду сливать бэкапы за месяц. :-)

Я в итоге для домашнего использования пользуюсь USB-винчестером (одним),
и бэкап запускаю вручную, подключив этот винчестер. И отключаю сразу
после того, как он завершился.
На прошлой работе, где я занимался бэкапами, бэкапы делались
автоматически, но в использовании было 5 сменных дисков, тоже USB, и
алгоритм их ротации, в соответствии с которым по крайней мере один в
любой момент находился вне офиса - либо у зам. генерального, либо у
админа дома. Вообще в любой момент. И копия на оном винте была,
соответственно, не старше двух рабочих дней.
Ну вы сравнили. Компания - это совсем другой разговор. Будь я каким-нибудь
Джобсом, хранящим на своём компьютере чертежи этого вашего айфона, у меня тоже
была бы ротация. И не пять дисков, а как минимум десять. И компания... :-D

Re: Вопросы про бэкапы.

27.05.2012 16:51, Павел Марченко пишет:
 Вставлю и свои 5 копеек, на мой взгляд под задачу подходит
 Bacula(http://www.bacula.org/en/). Есть в дистрибутиве. По началу
 кажется очень сложной в настройке, но прочитав доку - все просто. 
Не, про Bacula я, конечно посмотрел. :-)
Не для локального компьютера. Это точно.
Она даже позиционируется, как система уровня предприятия.

 Делать слияние бэкапов не нужно, бэкала все задачи хранит в мускульной
 базе и сама знает какой полный или диффиренциальный бэкап последний и
 на основании этого троятся задачи.
К тому же, использует СУБД...
Там слишком много лишнего для моей задачи.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc24d78.60...@yandex.ru

Re: Вопросы про бэкапы.

Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 19:45:48 +0400:

Понимаю. Но backup сервером является мой комп, за которым я и сижу.
Только диски
отличаются. Бэкап мне нужен на случай, если что-то капитально упадёт
(давно
такого не было, но всё-таки).
Так что, если он будет скомпрометирован, бэкап защищать уже не
придётся. :-)
Просто мне спокойнее, когда на диске все потенциально чувствительные
данные
шифруются.
Я посмотрю на твой бэкап когда у тебя БП сожжёт диски после скачка
напряжения.
АН Хотя, конечно, возможно делать бэкап, например, на ноут. Но опять же:
гонять
АН данные по сети (даже несмотря на инкрементальные бэкапы, ведь он
подключен по
АН wi-fi), настраивать всё на ноуте, держать его включённым...
АН Ради чего, у меня не такие серьёзные данные?

Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
либо не достойны - и тогда их не надо бэкапить вообще. А _делать вид_,
что бэкапишь - это как-то странно...
АН С чего вы взяли, что я делаю вид?
АН Я создаю дубликат нужных мне данных на отдельном диске.
АН Это снижает вероятность потери.

Снижает. Но на гораздо меньшую величину, чем создает _ощущение_
защищенности данных.

Вообще первая аксиома бэкапа - достаточно свежая резервная копия данных
должна находиться на носителе, физически отключенном от основной копии и
желательно географически отдаленном.
АН Второе - слишком дорого и того не стоит.
АН Физически диски разделены. Поскольку бэкап создаётся автоматически смысла в
АН отключении мало, а покупать ещё один диск - это накладно.

USB-диск ноутбучного формата стоит копейки, а запустить скрипт бэкапа
вручную - единицы секунд.

Для домашнего бэкапа иногда можно
пренебречь идеей, что такое должно выполняться в абсолютно любой момент
(и иметь один съемный бэкапный винчестер, а не минимум два), и хранить
копию в той же квартире. Но хранить ее подключенной к тому же
контроллеру - не очень умное действие.
АН Во-первых, второй диск внутренний.
АН Во-вторых, пока мне такое не требуется и одного постоянно подключенного
диска
АН хватит. Если в будущем мои данные я оценю дороже, я приобрету внешний
винчестер,
АН на который буду сливать бэкапы за месяц. :-)

Цена данных обычно сильно увеличивается после их потери :-)

Я в итоге для домашнего использования пользуюсь USB-винчестером (одним),
и бэкап запускаю вручную, подключив этот винчестер. И отключаю сразу
после того, как он завершился.
На прошлой работе, где я занимался бэкапами, бэкапы делались
автоматически, но в использовании было 5 сменных дисков, тоже USB, и
алгоритм их ротации, в соответствии с которым по крайней мере один в
любой момент находился вне офиса - либо у зам. генерального, либо у
админа дома. Вообще в любой момент. И копия на оном винте была,
соответственно, не старше двух рабочих дней.
АН Ну вы сравнили. Компания - это совсем другой разговор. Будь я каким-нибудь
АН Джобсом, хранящим на своём компьютере чертежи этого вашего айфона, у меня
тоже
АН была бы ротация. И не пять дисков, а как минимум десять. И компания... :-D

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

Re: Вопросы про бэкапы.

Артём Н. - debian-russian@lists.debian.org @ Sun, 27 May 2012 19:34:55 +0400:

Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
либо не достойны - и тогда их не надо бэкапить вообще.
Чушь.
Аргументируйте.
АН Я аргументирую.
АН 1. Довольно странное утверждение, смахивает на проявление максимализма.

Хинт: серьезно не означает противопожарного сейфа и охранников с
автоматом. Серьезно означает подумав о вариантах развития событий,
особенно - неприятных.

Сбой контроллера или драйвера контроллера - не сильно более редкая вещь,
чем физический вылет винчестера. Более-менее одновременный вылет двух
винчестеров, постоянно крутящихся в одной машине, особенно если они из
одной партии - тоже не шибко редок. А уж взлом с порчей всех файловых
систем, до которых дотянется ломалка - и более частая. Съемный
винчестер весьма дешево снимает _все_ эти проблемы с вероятностью,
близкой к 1, а бэкап в ту же машину - только одну, причем не самую
вероятную. Вот отсутствие такой оценки - это несерьезно.

Остальное бла-бла-бла, конечно, более-менее правдоподобно, но похоже на
повторение без понимания.

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Dmitry Nezhevenko

Andrey Rahmatullin - debian-russian@lists.debian.org  @ Sun, 27 May 2012 
21:09:14 +0600:

Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить серьезно,
либо не достойны - и тогда их не надо бэкапить вообще. 
   Чушь.
  Аргументируйте.
 AR Пусть Чуприна аргументирует.

С дискутантами, начинающими дискуссию с оценочного суждения,
дискутировать не дискутантно.  Если б ты вежливо попросил аргументов...
Их есть у меня, если что.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcjhmn24@wizzle.ran.pp.ru

Re: Что-то сломал в кедах. Теперь нет звука совершенно.

2012-05-27 Пенетрантность basilio

Для меня gnome2 был последним десктопным окружением, в котором можно
было комфортно и продуктивно работать, все правильно автоматически
определялось и ничего не отваливалось. После него во всех популярных
десктопах плюшки победили функциональность (имхо). В поисках разумного
перешел на тайлинг (осом) и, в основном, ручное управление системой.
Сначала были некоторые сложности [из-за недостаточного знания системы],
но они легко локализуются и постепенно уходят. Зато теперь все работает
и есть уже почти достаточное, хотя-бы для того, чтобы себя обслужить,
представление о системе. Чего и Вам желаю.

Пардон за офтоп.

А насчет звука - кроме alsa я б еще в сторону phonon копнул бы, может
там отвалилось чего.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jpu0gn$gb9$1...@dough.gmane.org

Re: Вопросы про бэкапы.

On Sun, May 27, 2012 at 07:34:55PM +0400, Артём Н. wrote:
 4. Если стоимость бэкапа превышает стоимость данных, необходимости в таком
 бэкапе нет.
 Пример: фотографии достаточно залить на флешку, но делать для них систему 
 бэкапа
 (даже, если они меняются) - неразумно. Слишком сложно и не стоит того.

Я бы скорее к этому музыку отнес. А некоторые фотографии могут быть дороги
как память. И восстановить их может быть невозможно вообще.
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Konstantin Fadeyev

Я для дома использую связку dropbox+cryptkeeper. Для документов
хватает. Ну и шифрование какое-никакое.
Есть скрипт который по крону туда мне копирует некоторые файлы
настроек и ещё кое-какую мелочёвку не из домашней папки. Вот пожалуй и
всё.
На работе пользуюсь такой схемой:
1. Документы (doc, xsl, ppt, odt и так далее) по расширению, в 7z
архив раз в сутки. Архивы старше 91 дня удаляются.
2. Мультимедийный контент (jpg, avi и так далее) по расширению, в 7z
архив без сжатия (7z для единообразия) раз в 2 недели. Архивы старше
61 дня удаляются.
3. Полный архив в 7z раз в месяц. Архивы старше 357 дней удаляются.

Схема несовершенна, например копии документов и мультимедиа
синхронизированы только 2 раза в месяц. Файлы которые не попали в
список расширений вообще в непонятном состоянии. Ежемесячный бэкап
весьма крупный.
Плюсов два, возможность быстро что-то вытянуть и схема относительно проста.
Повода сменить пока небыло, вот и пользуемся.

--
Константин Фадеев

Re: Вопросы про бэкапы.

On Sun, May 27, 2012 at 11:38:43PM +0400, Artem Chuprina wrote:
 Либо у тебя данный достойны бэкапа - и тогда их надо бэкапить 
 серьезно,
 либо не достойны - и тогда их не надо бэкапить вообще. 
Чушь.
   Аргументируйте.
  AR Пусть Чуприна аргументирует.
 С дискутантами, начинающими дискуссию с оценочного суждения,
 дискутировать не дискутантно.
А чего тут дискутировать? Высказано категоричное мнение, являющееся
ошибочным, опровергать я его не собираюсь.

 Если б ты вежливо попросил аргументов...
Зачем они мне? Мне достаточно контрпримеров.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Что-то сломал в кедах. Теперь нет звука совершенно.

2012-05-27 Пенетрантность SHURE MICROPHONE

On Sun, May 27, 2012 at 10:49:43PM +0300, basilio wrote:
 А насчет звука - кроме alsa я б еще в сторону phonon копнул бы, может
 там отвалилось чего.
Вы б смотрели, на что отвечаете.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Victor Wagner

On 2012.05.27 at 22:57:34 +0300, Dmitry Nezhevenko wrote:

On Sun, May 27, 2012 at 07:34:55PM +0400, Артём Н. wrote:
4. Если стоимость бэкапа превышает стоимость данных, необходимости в таком
бэкапе нет.
Пример: фотографии достаточно залить на флешку, но делать для них систему
бэкапа
(даже, если они меняются) - неразумно. Слишком сложно и не стоит того.

Я бы скорее к этому музыку отнес. А некоторые фотографии могут быть дороги
как память. И восстановить их может быть невозможно вообще.

А вот их (поскольку они не меняются никогда) нужно бэкапить на
write-only носители по мере поступления. Поскольку такой бэкап не
перестанет быть актуальным никогда (он может перестать быть полным, но
дописать и положить в эту коробку еще один диск - и ура).

Правда, write-only носители тоже иногда выходят из строя. Но вроде,
если не слишком экономить на болванках, получается достаточно живуче.

SHURE MICROPHONE与您共享了照片


Hi,sir

thank you very much for your time

attached is shure mic , yamaha speaker and crown amp, dbx speaker  
andsenhiser mic prices list.


if you are interest, can you contact us?

Steven
www.newplayaudio.net
attachment: 音响图片.jpg

Re: Вопросы про бэкапы.

2012-05-27 Пенетрантность Stanislav Vlasov

28 мая 2012 г., 10:42 пользователь Victor Wagner vi...@wagner.pp.ru написал:

 Правда, write-only носители тоже иногда выходят из строя.  Но вроде,
 если не слишком экономить на болванках, получается достаточно живуче.

dvd - 5 лет в среднем на моём архиве... Если, конечно, хранить в
домашних условиях (в шкафу при комнатной температуре). Сейчас думаю,
куда бы заархивировать домашний видеоархив...

-- 
Stanislav

Re: Вопросы про бэкапы.