Re: актуальный софт для инкрементального backup

On Wed, 25 Nov 2020 17:27:31 +0200 Sohin Vyacheslav wrote: > Посоветуйте плз актуальный софт для удобного (в плане конфигурации) > инкрементального резервного копирования десятков, в перспективе сотен > серверов linux. backuppc, но как у него с сотнями серверов будет, не знаю -- С уважен

Re: актуальный софт для инкрементального backup

27.11.2020 23:30, Alexander Pytlev пишет: Proxmox выкатил свой бэкап-сервер https://forum.proxmox.com/threads/proxmox-backup-server-1-0-stable.78851/post-349107 , получилась интересная штука. согласен, надо будет его проюзать, спасибо за линк. -- BW, Сохин Вячеслав

Re: актуальный софт для инкрементального backup

om/threads/proxmox-backup-server-1-0-stable.78851/post-349107 , получилась интересная штука. В нём есть не только инкрементальный бэкап. Сервер можно поставить поверх уже установленного Debian. Клиент  правда пока только под Debian, брать из их репозитория. -- See You. WBW

Re: актуальный софт для инкрементального backup

25.11.2020 19:42, Victor Wagner пишет: Ну это зависит от того, куда именно резервно копировать. Если на носитель с файловой системаой (какой-нибудь NAS) то, возможно, удобным окажется rshapshot. У меня, конечно, десятков серверов нет, но пользуюсь именно им. да, планируется использовать NAS.

Re: актуальный софт для инкрементального backup

В Wed, 25 Nov 2020 17:27:31 +0200 Sohin Vyacheslav пишет: > Приветствую, > > Посоветуйте плз актуальный софт для удобного (в плане конфигурации) > инкрементального резервного копирования десятков, в перспективе сотен > серверов linux. > Ну это зависит от того, куда именно резервно копировать

актуальный софт для инкрементального backup

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

Re: Backup

Выложу своё "исследование" отдельной темой. Может кому пригодится. 28.02.2018 13:21, Sergey Spiridonov пишет: > Привет > > On Thu, 15 Feb 2018 22:59:07 +0300 > artiom wrote: > >> Подскажите, чем возможно выполнять резервное копирование нескольких >> машин по сети, чтобы условия ниже были удовле

Re: Backup

Привет On Thu, 15 Feb 2018 22:59:07 +0300 artiom wrote: > Подскажите, чем возможно выполнять резервное копирование нескольких > машин по сети, чтобы условия ниже были удовлетворены. Под описание полностью подходит backuppc. Единственное чего нет из коробки - репликации в облако, но это несложно

Re: Backup

К счастью, по мне это не било. >> Один >> >> >> раз - только потому, что у меня был еще и свой бэкап. >> >> >> >> >> > Но ведь система специально заточена под бэкап, долго живёт и >> развивается. >> >> > Почему не было успешно её применение? >> >> > Возможно ли, что это просто было неправильное использование? >> >> >> >> Да. Вопрос в том, кому по карману правильное. Может быть, >> хостинг-провайдеру. >> >> >> > В таком случае, по каким причинам они выбирают Bacula-like? >> >> Не могу дать гарантированного ответа, но вероятно, купившись на >> рекламные слова. Иногда еще, чтобы было чем оправдываться перед >> начальством за продолбы. Типа, "мы использовали проверенный бэкапный >> софт, и не виноваты, что не смогли восстановить требуемое". Если тот же >> самый продолб (он обычно организационного характера) произойдет с >> велосипедным решением, оправдываться будет сложнее. >> > Разве это единственная причина? В этом абзаце я привел две :) Так вот сходу могу привести третью (она, по сути, модификация первой): что первое нагуглилось по запросу типа "backup software", то и выбрали. Я думаю, при желании можно придумать еще, но ценность ответа на вопрос ниже, чем ценность 10 минут времени, которые съест этот процесс.

Re: Backup

artiom -> debian-russian@lists.debian.org @ Tue, 20 Feb 2018 21:07:30 +0300: >> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные >> >> >> >> продвинутые инкрементальные средства бэкапа, типа той же >> бакулы, дает >> >> >> >> первое и второй ценой невозможности тр

Re: Backup

21.02.2018 08:01, Victor Wagner пишет: > В Tue, 20 Feb 2018 20:56:03 +0300 > artiom пишет: > > ю, сбой диска убьет >>> единственный. >> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в >> целом, я считаю, подход неправильный. >> Надёжность хранилища должна нижним уровнем о

Re: Backup

В Tue, 20 Feb 2018 20:56:03 +0300 artiom пишет: ю, сбой диска убьет > > единственный. > Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в > целом, я считаю, подход неправильный. > Надёжность хранилища должна нижним уровнем обеспечиваться. > Явно не прикладным, на котором рабо

Re: Backup

> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные > >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, > дает > >> >> >> первое и второй ценой невозможности третьего. Обратный > инкрементальный, > >> >> >> как у rsync, второе и третье ценой н

Re: Backup

> >> >> >> >> В общем, анализировать бэкапные решения надо начинать не с > "где > >> >> >> >> хранить" и "какой транспорт использовать" а с "как будет > выглядеть > >> >> >> >> процедура восстановления". Причем в двух вариантах > >> >> >> >> > >> >> >> > Да, вообще явного ана

Re: Backup

18.02.2018 23:07, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:23:52 +0300: > > >> >> >> >> - rsync поддерживает использование ssh как транспорт, > существуют так же > >> >> >> >> надстройки разные > >> >> >> >> > >> >> >> > Да, rsync

Re: Backup

> >> > Касательно проверок: как это делается? > >> > На практике, там где это было, как проводится такая проверка в > >> > существующей инфраструктуре? > >> > >> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым > >> диском (обычно виртуалка, но по возможности иногда

Re: Backup

20.02.2018 18:10, Коротаев Руслан пишет: > В сообщении от [Вт 2018-02-20 16:34 +0200] > Dmitry Nezhevenko пишет: > >> Нет. Это не Page Cache. Память уходит на внутренние индексы restic и >> растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry >> Pi сейчас невозможно забэкапи

Re: Backup

пары ноутбуков плюс домашнего NAS. > Файлы достаточно сильно пересекаются, так что дедупликация очень сильно > экономит место (репозиторий около 1.5 TB, до этого пользовался > rdiff-backup и в сумме получалось около 2.5 TB). И это при том что restic > не умеет сжатие. Вообще никак.

Re: Backup

В сообщении от [Вт 2018-02-20 17:51 +0200] Dmitry Nezhevenko пишет: > А при чем тут minio? restic -- средство бэкапа, а minio -- просто > хранилище файлов. Не только, ещё есть клиент [1], можно легко перемещать данные между облаками, но нет шифрования и снапшотов как в restic. [1]: https://docs

Re: Backup

On Tue, Feb 20, 2018 at 08:10:24PM +0500, Коротаев Руслан wrote: > > prune по умолчанию не использует кэш. Он чем-то похож на git repack > > (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что > > весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на > > SSD.

Re: Backup

В сообщении от [Вт 2018-02-20 16:34 +0200] Dmitry Nezhevenko пишет: > Нет. Это не Page Cache. Память уходит на внутренние индексы restic и > растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry > Pi сейчас невозможно забэкапить на терабайтный репозиторий. > > Но планы почини

Re: Backup

On Tue, Feb 20, 2018 at 07:10:24PM +0500, Коротаев Руслан wrote: > Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод > команды free, если память потребляется за счет buff/cache, то всё в > порядке. У меня на виртуалке крутится Minio (прога схожая по > функциональности с resti

Re: Backup

В сообщении от [Пн 2018-02-19 12:58 +0200] Dmitry Nezhevenko пишет: > Оно очень сильно кушает RAM на клиенте. При чем потребление > пропорционально общему размеру репозитория. Для моих 1.5TB данных это > около 4GB RAM при бэкапе. Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите

Re: Backup

Victor Wagner -> debian-russian@lists.debian.org @ Mon, 19 Feb 2018 14:38:14 +0300: >> > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа >> > основной инфраструктуры ради проверки восстановления не >> > прерывается. >> >> Вообще говоря, возможны ситуации, когда приход

Re: Backup

On Sun, 18 Feb 2018 23:34:56 +0300 Artem Chuprina wrote: > > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа > > основной инфраструктуры ради проверки восстановления не > > прерывается. > > Вообще говоря, возможны ситуации, когда приходится прерывать. Потому > что оценить

Re: Backup

тся, так что дедупликация очень сильно экономит место (репозиторий около 1.5 TB, до этого пользовался rdiff-backup и в сумме получалось около 2.5 TB). И это при том что restic не умеет сжатие. Вообще никак. Из плюсов что увидел для себя: 1. Дедупликация. Это действительно очень удобно. До этого пы

Re: Backup

artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:15:25 +0300: >> >> Синхронизатор не отличает намеренное удаление или порчу от >> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в >> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и усп

Re: Backup

artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:23:52 +0300: >> >> >> >> - rsync поддерживает использование ssh как транспорт, >> существуют так же >> >> >> >> надстройки разные >> >> >> >> >> >> >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над

Re: Backup

artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:36:37 +0300: >> >> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc >> и >> >> >> >>> выбранные пользовательские данные. >> >> >> >> >> >> >> >> Меня в свое время убедили что не надо экономить

Re: Backup

>> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о >> ней не слышал. С ней есть какие-то проблемы? > > Я сам его нашел только вчера, но отзывы о нем хорошие, вот например > известный сервис Backblaze его рекомендует [2]. > Любопытно, что рекомендуют, статистику по дискам их

Re: Backup

> >> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и > >> >> >>> выбранные пользовательские данные. > >> >> >> > >> >> >> Меня в свое время убедили что не надо экономить те считанные > гигабайты, > >> >> >> которые занимает /usr и бэкапить и ее тоже. Чтобы п

Re: Backup

17.02.2018 19:19, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Sat, 17 Feb 2018 11:56:37 +0300: > > >> >> >> - rsync поддерживает использование ssh как транспорт, существуют > так же > >> >> >> надстройки разные > >> >> >> > >> >> > Да, rsync хорошая штука.

Re: Backup

> >> >> >> - NextCloud > >> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно > даёт, > >> >> > почему называется "облаком", легко ли его интегрировать с той же > Bacula > >> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл > >> >> > использ

Re: Backup

В сообщении от [Сб 2018-02-17 23:29 +0300] artiom пишет: > А вот про плеер возможно подробнее? > Я mpd хочу впилить. Обычный плеер [1] только в браузере. > Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о > ней не слышал. С ней есть какие-то проблемы? Я сам его нашел тольк

Re: Backup

17.02.2018 13:29, Коротаев Руслан пишет: > В сообщении от [Пт 2018-02-16 20:52 +0300] > artiom пишет: > >> Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки? > > Nextcloud? Да, конечно. Он всё-в-одном, не нужно носить с собой ноутбук, > у меня там почта, RSS-читалка, музыкаль

Re: Backup

artiom -> debian-russian@lists.debian.org @ Sat, 17 Feb 2018 10:39:21 +0300: >> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и >> >> >>> выбранные пользовательские данные. >> >> >> >> >> >> Меня в свое время убедили что не надо экономить те считанные >> гиг

Re: Backup

artiom -> debian-russian@lists.debian.org @ Sat, 17 Feb 2018 11:16:16 +0300: >> >> >> - git-annex - то, что и можно предположить: костыль над гитом. >> >> > `Git's man page calls it "a stupid content tracker". With git-annex, >> git >> >> > is instead "a stupid filename and metadata" t

Re: Backup

artiom -> debian-russian@lists.debian.org @ Sat, 17 Feb 2018 11:56:37 +0300: >> >> >> - rsync поддерживает использование ssh как транспорт, существуют >> так же >> >> >> надстройки разные >> >> >> >> >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним >> >> > п

Re: Backup

> >> >> - rsync поддерживает использование ssh как транспорт, существуют так > же > >> >> надстройки разные > >> >> > >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним > >> > придётся всё доделывать самостоятельно, а в той же Bacula большинство > >> > функций реали

Re: Backup

17.02.2018 00:35, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 22:25:22 +0300: > > >> >> - git-annex - то, что и можно предположить: костыль над гитом. > >> > `Git's man page calls it "a stupid content tracker". With git-annex, > git > >> > is inst

Re: Backup

17.02.2018 00:50, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 21:54:34 +0300: > > >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и > >> >>> выбранные пользовательские данные. > >> >> > >> >> Меня в свое время убедили что н

Re: Backup

artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 21:54:34 +0300: >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и >> >>> выбранные пользовательские данные. >> >> >> >> Меня в свое время убедили что не надо экономить те считанные гигабайты, >> >> котор

Re: Backup

artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 22:25:22 +0300: >> >> - git-annex - то, что и можно предположить: костыль над гитом. >> > `Git's man page calls it "a stupid content tracker". With git-annex, git >> > is instead "a stupid filename and metadata" tracker. The conte

Re: Backup

16.02.2018 10:39, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 08:25:39 +0300: > > >> - git-annex - то, что и можно предположить: костыль над гитом. > > `Git's man page calls it "a stupid content tracker". With git-annex, git > > is instead "a stupid f

Re: Backup

15.02.2018 23:31, grey.fenrir пишет: > 02/15/2018 10:59 PM, artiom пишет: >> Подскажите, чем возможно выполнять резервное копирование нескольких >> машин по сети, чтобы условия ниже были удовлетворены. > borgbackup весьма хорош В Automating backups они предлагают написать bash скрипт. На скринкас

Re: Backup

ное копирование хочу выполнять на центральное хранилище, с FreeNAS. >> Основные машины - PC с Debian и ноут с Debian. >> Ноут преимущественно подключен через Интернет, PC в локальной сети. > > Я использую backup-manager и скрипт-обвязку для LVN snapshot. > У меня всё кроме /boot —

Re: Backup

16.02.2018 09:13, Сергей Цаболов пишет: > Доброе утро! > > Я сказал бы что  есть довольное хорошее решение > > https://serveradmin.ru/backup-linux-servera-s-pomoshhyu-duplicity/ > Почитал статью, и не понял, что хотел сказать автор. В начале он rsync упоминает. Переехал ли

Re: Backup

оказались повреждены (не > > ОС, с ней всё в порядке, а то, на что пользователь имеет права). > > 5. Требуется восстановить часть данных с одного устройства на другом (с > > целью синхронизации, например). > > При вменяемой системе бэкапа все три пункта - это одно и то ж

Re: Backup

> Hexawolf -> debian-russian@lists.debian.org @ Thu, 15 Feb 2018 23:28:13 > +0200: > > > Ещё варианты: > > > - git-annex - то, что и можно предположить: костыль над гитом. > > - SparkleShare - что-то весьма минималистичное > > - NextCloud > > - SyncThing > > - rsync поддерживает использов

Re: Backup

16.02.2018 09:48, kuzminov пишет: > On 16.02.2018 08:25, artiom wrote: >> >> >> >>> - SyncThing >> Сам уже нашёл. >> Хотелось бы о нём услышать отзывы использующих. >> По мне: весьма интересная штука. >> > Это программа для синхронизации папок, а не резервного копирвания. Очень > простая и работа

Re: Backup

Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки? Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке", когда NAS может предоставить их отдельно (подняв FTP сервер, например)? 16.02.2018 09:06, Коротаев Руслан пишет: > В сообщении от [Пт 2018-02-16 08:25 +0300]

Re: Backup

Спасибо. Посмотрю. В чём основная разница с Бакулой? 16.02.2018 09:19, Павел Марченко пишет: > Bareos это форк Бакулы, причем довольно успешный > > > > 15 февр. 2018 г. 23:46 пользователь "artiom" > написал: > > > Без допилов только проприетарщина. > Однозна

Re: Backup

ноут с Debian. Ноут преимущественно подключен через Интернет, PC в локальной сети. Я использую backup-manager и скрипт-обвязку для LVN snapshot. У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее: 1. создаём lvm snapshot для желаемых разделов; 2. монтируем эти снимки в /mnt

Re: Backup

On 16.02.2018 08:25, artiom wrote: - SyncThing Сам уже нашёл. Хотелось бы о нём услышать отзывы использующих. По мне: весьма интересная штука. Это программа для синхронизации папок, а не резервного копирвания. Очень простая и работает как ожидается примерно. Версионность неудобная, куча фа

Re: Backup

artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 08:43:17 +0300: > Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть. Он их использует только на бэкап-сервере. Если же их нет на его ФС, то вопрос в непрофильную рассылку :) >>> Также, в перспективе, могут резервироват

Re: Backup

Victor Wagner -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 07:49:34 +0300: >> Также, в перспективе, могут резервироваться машины с Windows и MacOS, >> возможно Android планшет. > Вот windows rsync-ом не забэкапишь. Систему нет, а пользовательские данные еще как. > Windows я в сво

Re: Backup

artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 08:25:39 +0300: >> - git-annex - то, что и можно предположить: костыль над гитом. > `Git's man page calls it "a stupid content tracker". With git-annex, git > is instead "a stupid filename and metadata" tracker. The contents of > an

Re: Backup

Hexawolf -> debian-russian@lists.debian.org @ Thu, 15 Feb 2018 23:28:13 +0200: > Ещё варианты: > - git-annex - то, что и можно предположить: костыль над гитом. > - SparkleShare - что-то весьма минималистичное > - NextCloud > - SyncThing > - rsync поддерживает использование ssh как транспор

Re: Backup

Bareos это форк Бакулы, причем довольно успешный 15 февр. 2018 г. 23:46 пользователь "artiom" написал: > Без допилов только проприетарщина. Однозначно - нет. Про всякие Veeam я в курсе: не хочу использовать, т.к. имею представление о том, что там внутри. Минимальные допилки и настройку восприн

Re: Backup

>> Ещё варианты: luckybackup - надстройка над rsync, при личном использовании - никаких нареканий; бэкапит, что скажешь. -- Евгений Кабанов

Re: Backup

ну (по расписанию) > Да, я помню, вы её предлагали, когда я ещё бэкапилку для одной машин делал. Я тогда rdiff-backup выбрал, но сейчас бы остановился на rsnapshot. Тем не менее, доделок много придётся сделать. Для чего мне реализовывать функционал Bacula самому? Какие плюсы есть у rsnapshot?

Re: Backup

16.02.2018 00:28, Hexawolf пишет: > Ещё варианты: > > - git-annex - то, что и можно предположить: костыль над гитом. `Git's man page calls it "a stupid content tracker". With git-annex, git is instead "a stupid filename and metadata" tracker. The contents of annexed files are not stored in git,

Re: Backup

В Thu, 15 Feb 2018 22:59:07 +0300 artiom пишет: > Подскажите, чем возможно выполнять резервное копирование нескольких > машин по сети, чтобы условия ниже были удовлетворены. > > Склоняюсь к следующим вариантам: > > - Bacula. > - BackupPC. > - Решения на базе rsync. > > Изо всего работал только

Re: Backup

Ещё варианты: - git-annex - то, что и можно предположить: костыль над гитом. - SparkleShare - что-то весьма минималистичное - NextCloud - SyncThing - rsync поддерживает использование ssh как транспорт, существуют так же надстройки разные Ничего не знаю по поводу "репликации в облко с шифрованием"

Re: Backup

> Без допилов только проприетарщина. Однозначно - нет. Про всякие Veeam я в курсе: не хочу использовать, т.к. имею представление о том, что там внутри. Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не пришлось делать своё "кастомное решение". > В остальном Бакула точнее её ф

Re: Backup

Плюсом сюда идут вопросы, по только что узнанному мной OwnCloud/NextCloud. В чём разница с Bacula? Имеет смысл?

Re: Backup

02/15/2018 10:59 PM, artiom пишет: Подскажите, чем возможно выполнять резервное копирование нескольких машин по сети, чтобы условия ниже были удовлетворены. borgbackup весьма хорош Также, в перспективе, могут резервироваться машины с Windows и MacOS, возможно Android планшет. работает на macos

Re: Backup

Без допилов только проприетарщина. В остальном Бакула точнее её форк. 15 февр. 2018 г. 22:59 пользователь "artiom" написал: > Подскажите, чем возможно выполнять резервное копирование нескольких > машин по сети, чтобы условия ниже были удовлетворены. > > Склоняюсь к следующим вариантам: > > - Bac

Backup

Подскажите, чем возможно выполнять резервное копирование нескольких машин по сети, чтобы условия ниже были удовлетворены. Склоняюсь к следующим вариантам: - Bacula. - BackupPC. - Решения на базе rsync. Изо всего работал только с rsync, о Bacula имею представление, а BackupPC мне неизвестен. Рез

Re: Вечная тема: посоветуйте backup систему

Посмотрите backupninja.  Немного цитат из мана: - you can drop in scripts to handle new types of backups. - you can choose when status report emails are mailed to you (always, on warning, on error, never). - console-based wizard (ninjahelper) makes it easy to create backup action configuration

Re: Вечная тема: посоветуйте backup систему

ся, чтобы он долго жил. > * желательно из имеющихся пакетов. > > apt-get search backup я делать умею, но: > > * там их много всяких; > * нужный пакет может не иметь в имени *backup*; > * мало ли чего эти пакеты обещают. > > Ваши советы, рекомендации, ссылки? Вот з

Re: Вечная тема: посоветуйте backup систему

Леонид Кальмаев -> debian-russian@lists.debian.org @ Mon, 27 Mar 2017 20:43:00 +0700: > Тык rsnapshot и не выпендриваться, не? С базами данных так лучше не выпендриваться. Особенно с недобазами. Можно получить бэкап, который потом не заведется.

RE: Вечная тема: посоветуйте backup систему

; Тема: Вечная тема: посоветуйте backup систему Дано: * маленькая конторская локальная сеть; * сервер для бэкапов: devuan/jessy, amd64, 4-х дисковое зеркало на mdadm; * сервер - источник бэкапов: debian/squeeze (6.0.10), обновлять нельзя; один каталог ~ 400 МБ + mysql ~ 50 МБ. mysql сейчас бэкап

Re: Вечная тема: посоветуйте backup систему

Тык rsnapshot и не выпендриваться, не?

Re: Вечная тема: посоветуйте backup систему

SSD и хочется, чтобы он долго жил. > *  желательно из имеющихся пакетов. > > apt-get search backup я делать умею, но: > > * там их много всяких; > * нужный пакет может не иметь в имени *backup*; > * мало ли чего эти пакеты обещают. > > Ваши советы, рекомендации, ссылки? Неплохая вещь. https://github.com/backup/backup

Re: Вечная тема: посоветуйте backup систему

03/27/2017 08:29 PM, Дмитрий Фёдоров пишет: * клиент-серверный инкрементальный бэкап, желательно не создающий нагрузки записи на диск сервера - источника, так как там SSD и хочется, чтобы он долго жил. * желательно из имеющихся пакетов. borgbackup мне тут с полгода назад советовали и мне оч

Вечная тема: посоветуйте backup систему

хочется... Хочу: * клиент-серверный инкрементальный бэкап, желательно не создающий нагрузки записи на диск сервера - источника, так как там SSD и хочется, чтобы он долго жил. * желательно из имеющихся пакетов. apt-get search backup я делать умею, но: * там их много всяких; * нужный пакет

Re: backup bike

11/28/2016 11:49 PM, Dmitri V. Ivanov пишет: On Sun, Nov 27, 2016 at 05:10:14AM +0300, 9211297 wrote: > сеть. Файловые системы - строго наитивные (сейчас фактически только > ext4). Разумеется, через некоторое время (или размер инкремента) ??? > полный бэкап. На нативных строгий инкремент дает а

Re: backup bike

On Sun, Nov 27, 2016 at 05:10:14AM +0300, 9211297 wrote: > сеть. Файловые системы - строго наитивные (сейчас фактически только > ext4). Разумеется, через некоторое время (или размер инкремента) ??? > полный бэкап. На нативных строгий инкремент дает алгоритм, вшитый в GNU tar с опцией --listed-inc

Re: backup bike

2016-11-27 10:37 GMT+01:00 Михаил Касаджиков : > 27.11.2016 05:10, 9211297 пишет: > > Приветствую. > > Хочу строить велосипед, но думаю, что зря - должно же быть что-то именно > такое. Прошу подтвердить или опровергнуть. > > Задача: инкрементальные автоматизированные бэкапы некоторых частей $HOME

Re: backup bike

gt; представить на них инкремент. > > > - > Лев Б. > backup-manager Инкрементарные бэкапы, заливка куда-нить, шифрование с помощью pgp. Программа простая, на баше. Никаких центральных серверов и прочего ынтерпрайза. Проще только сам tar.

RE: backup bike

Bacula. Все перечисленное может. Складывает в девайс или в указанную фс. -Исходное сообщение- От: "9211297" <9211...@gmail.com> Отправлено: ‎27.‎11.‎2016 5:27 Кому: "debian-russian@lists.debian.org" Тема: backup bike Приветствую. Хочу строить велосипед, но

Re: backup bike

Посмотрите на rdiff-backup. Может инкрементить локально, может по ssh. Всегда хранится актуальная копия, а прошлые снимки как последовательные инктеременты к с самому свежему. -- Дмитрий telegram: @dmitryrw   9211297 <9211...@gmail.com> 27 ноября 2016 г. 7:27:11 написал: Приветствую

backup bike

Приветствую. Хочу строить велосипед, но думаю, что зря - должно же быть что-то именно такое. Прошу подтвердить или опровергнуть. Задача: инкрементальные автоматизированные бэкапы некоторых частей $HOME на одном, максимум - двух хостах (соответственно, могут быть не совсем автоматизированы, что-

Re: full backup of server with LVM and mdadm to usb hard drive

апшоты один за другим до начала резервного копирования. Потом монтирую снапшоты и делаю их бэкап через rdiff-backup. -- WBR, Andrey Tataranovich -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists

Re: full backup of server with LVM and mdadm to usb hard drive

On 22.08.2013 16:36, Andrey Tataranovich wrote: 4. Скопировали по очереди через dd все группы томов (предварительно делая снапшоты) Снапшоты лучше делать не последовательно, а "атомарно" иначе на можно получить неконсистентный бэкап. Это однозначно ударит по производительности диска, но целостно

Re: full backup of server with LVM and mdadm to usb hard drive

15:35 Thu 22 Aug, Владимир Скубриев wrote: > План примерно такой скрипта: > > 1. Проверили что мы будем делать бэкап рабочих винтов на внешний диск > 2. Сделали разметку usb винта > 3. Скопировали настройку lvm на usb винт Если бэкап нужен для bare-metal recovery, то посмотрите на mondorescue

full backup of server with LVM and mdadm to usb hard drive

План А - все архивируется файлами на другой сервер. Восстанавливаю все ручками в случае если зеркало на рабочем сервере полетит. Загружась с флэшки. Настраиваю сеть. Копирую все с архивного сервера. План Б ниже full backup of server with LVM and mdadm to usb hard drive Планирую реализовать

Re: Удаление старых инкрементов rdiff-backup на большом архиве

On Fri, Mar 22, 2013 at 08:20:17PM +0300, Andrey Tataranovich wrote: > > > > > Да, вы правы. Я уже набросал аналогичный кусок кода и в нем все в > > > > > порядке. Получается > > > > > проблему нужно искать где-то в недрах rp.delete. > > > > Вам бы с третьего правила оптимизации начать было. > > >

Re: Удаление старых инкрементов rdiff-backup на большом архиве

23:16 Fri 22 Mar, Andrey Rahmatullin wrote: > On Fri, Mar 22, 2013 at 08:10:57PM +0300, Andrey Tataranovich wrote: > > > > Да, вы правы. Я уже набросал аналогичный кусок кода и в нем все в > > > > порядке. Получается > > > > проблему нужно искать где-то в недрах rp.delete. > > > Вам бы с треть

Re: Удаление старых инкрементов rdiff-backup на большом архиве

On Fri, Mar 22, 2013 at 08:10:57PM +0300, Andrey Tataranovich wrote: > > > Да, вы правы. Я уже набросал аналогичный кусок кода и в нем все в > > > порядке. Получается > > > проблему нужно искать где-то в недрах rp.delete. > > Вам бы с третьего правила оптимизации начать было. > > Подробности? htt

Re: Удаление старых инкрементов rdiff-backup на большом архиве

23:06 Fri 22 Mar, Andrey Rahmatullin wrote: > On Fri, Mar 22, 2013 at 08:04:35PM +0300, Andrey Tataranovich wrote: > > Да, вы правы. Я уже набросал аналогичный кусок кода и в нем все в порядке. > > Получается > > проблему нужно искать где-то в недрах rp.delete. > Вам бы с третьего правила опти

Re: Удаление старых инкрементов rdiff-backup на большом архиве

On Fri, Mar 22, 2013 at 08:04:35PM +0300, Andrey Tataranovich wrote: > Да, вы правы. Я уже набросал аналогичный кусок кода и в нем все в порядке. > Получается > проблему нужно искать где-то в недрах rp.delete. Вам бы с третьего правила оптимизации начать было. -- WBR, wRAR signature.asc Descri

Re: Удаление старых инкрементов rdiff-backup на большом архиве

22:03 Thu 21 Mar, Andrey Rahmatullin wrote: > On Wed, Mar 20, 2013 at 03:30:20PM +0300, Andrey Tataranovich wrote: > > Пробовал смотреть исходники rdiff-backup в районе remove-older-than > > > > # /usr/share/pyshared/rdiff_backup/manage.py > > > > def

Re: Удаление старых инкрементов rdiff-backup на большом архиве

On Wed, Mar 20, 2013 at 03:30:20PM +0300, Andrey Tataranovich wrote: > Пробовал смотреть исходники rdiff-backup в районе remove-older-than > > # /usr/share/pyshared/rdiff_backup/manage.py > > def delete_earlier_than_local(baserp, time): > """Lik

Re: Удаление старых инкрементов rdiff-backup на большом архиве

исляется. > > Сделал: > > # find /backup/server > filelist.txt > # ls -lh filelist.txt > -rw-r--r-- 1 root root 4.9G Mar 20 21:42 filelist.txt > > # wc -l filelist.txt > 27828638 filelist.txt > > Получается, чтобы итератор отработал до конца мне нужно мин

Re: Удаление старых инкрементов rdiff-backup на большом архиве

15:30 Wed 20 Mar, Andrey Tataranovich wrote: > Мой вылез за пределы 27 млн. инод - это всего 51 инкремент > (ежедневный бэкап за последних 50 дней). Объем архива пока сказать > не могу, он еще вычисляется. Сделал: # find /backup/server > filelist.txt # ls -lh filelist.txt -rw-r

Удаление старых инкрементов rdiff-backup на большом архиве

Доброго времени суток. У кого есть опыт работы с объемными архивами в rdiff-backup? Мой вылез за пределы 27 млн. инод - это всего 51 инкремент (ежедневный бэкап за последних 50 дней). Объем архива пока сказать не могу, он еще вычисляется. При попытке выполнить rdiff-backup

Re: /var/backup

В Sun, 04 Mar 2012 16:59:53 +0400 sergio пишет: > Всем привет. > > Мне тут вот подумалось, а почему бы не разнести файлы в /var/backup по > каталогам, а то там помойка получается. Я у себя сделал, мне нравится. > Чем это может быть плохо? Багрепорты стоит оформить? > Та н

/var/backup

Всем привет. Мне тут вот подумалось, а почему бы не разнести файлы в /var/backup по каталогам, а то там помойка получается. Я у себя сделал, мне нравится. Чем это может быть плохо? Багрепорты стоит оформить? -- sergio. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with

  1   2   3   4   5   >