Deutsch

Система контроля версий и бекап для распределенных бекапов

1649  1 2 3 все
wasja-de постоялец03.12.23 11:34
NEW 03.12.23 11:34 
Последний раз изменено 03.12.23 12:18 (wasja-de)

Добрый день,


посоветуйте, пожалуйста, бесплатный сабж. Имеется 4-6 пользователей под линукс (убунта), которые совместно девелопят проект, в котором не только много данных и компиляторов (используется веб, С/С++, ембеддед, плиски, питон, скрипты), но и имеется много (терабайты) данных. Пока все на общественных началах, поэтому на старье, что у кого было под рукой.


Имеется небольшой сервер в сети (300ГБ есть свободных) и есть переносные системы бекапов, в которые можно вставлять старые, но еще живые HDD суммарно на 50ТБ, у каждого есть просто свой лаптоп (не новый, а какой есть).


Что хочется.


Иметь какой-то разумный список дирректорий на каждом лаптопе, для которых писать какие-то атрибуты, и на основе решать следующие задачи:

1. Поддерживать контроль версий для разработки софта, там данных мало, до миллиона строк кода мы врят ли добежим, но больше ста тысяч строк будет однозначно.

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

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

4. Надо также иметь обычный бекап раз в день и раз в месяц, желательно всех данных и софта.

5. Данных за день может нагенериться на пару терабайт, иногда данные надо распределять друг между другом, иногда, по прошествии какого-то времени выбрасывать. У каждого разные лаптопы, у кого-то всего с системой 500ГБ, у кого-то 4ТБ.

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


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


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


Спасибо!

#1 
AlexNek патриот03.12.23 20:35
AlexNek
03.12.23 20:35 
в ответ wasja-de 03.12.23 11:34

Для начала давайте делить задачи... Или хочется всё в одном?


на каких системах контроля версий

Думаю git вполне подойдет для исходников и не очень больших бинов.

Сделал общий репозиторий, скачал копию себе и ушел. после синхронизация


Компиляторы

Видимо докер. Сделал оригинальный снимок и пользуй где нужно.


бекап

https://www.2brightsparks.com/syncback/sbpro.html давно пользуюсь очень доволен и цена божеская

#2 
wasja-de постоялец03.12.23 21:41
NEW 03.12.23 21:41 
в ответ AlexNek 03.12.23 20:35, Последний раз изменено 03.12.23 21:47 (wasja-de)

Спасибо за ответ!!!


Для начала давайте делить задачи... Или хочется всё в одном?


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


То есть пример - двое из команды со своими лаптопами (500ГБ и 4ТБ) наснимали данных суммарно на 2ТБ где-то в поле без доступа к интернету (в Швейцарии роуминг и народ пожмотил), тот, у кого 4ТБ - сохранился у себя, другой сохранил часть, что посчитал нужной для него. Они разъехались, отослали на сервер сорсы апдейтов и док репорта, остальные через время захотели вытащить данные посмотреть, но тот, кто у себя взял все, уже успел забыть отчекить это куда-то, да и не куда, на сервере в сети есть только 300ГБ, а на внешних дисках, что туда-сюда из рук в руки передаются, кто-то чего-то подзабыл сохранить. Потом получилась неразбериха и все поругались обвиняя друг друга в раздолбайстве.


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


А для сорсов да, что-то вроде гита, или все-таки cvs - это верно. Но не хочется кучи всего и разного, а хочется из одного флакона. И чтоб сравнения данных умело делать не качая данные по сети. То есть грубо говоря у двух на лаптопах есть даные по 200ГБ, и система по контрольной сумме детектировала, что это - одно и то же, и если у одного не хватает места, он может бросить запрос с фразой "можно я у себя удалю" чтобы локально новые данные нагенерить, но чтобы потом при необходимости эти данные к нему, если это нужно, снова приедут.


https://www.2brightsparks.com/syncback/sbpro.html давно пользуюсь очень доволен и цена божеская


Спасибо большое за ссылку, как я понимаю, они линукс не поддерживают? К сожалению, дальше не смотрел из-за этого.

#3 
AlexNek патриот03.12.23 22:17
AlexNek
NEW 03.12.23 22:17 
в ответ wasja-de 03.12.23 21:41
они линукс не поддерживают?

никогда не интересовался. Там другой мир...


Ибо есть проблемка - данные могут быть большими

Не думаю, что есть что то готовое. Возможно что то свое с гитом скрестить.

Типа для больших файлов делаем файл ссылку: (контрольная сумма, у кого оригинал, где будет копия, и т.п.)

может проще micro sd card по почте слать?


на сервере в сети есть только 300ГБ

А что мешает сделать больше? Буквально на неделе искал хороший 7200 диск, меньше 2 терабайт не нашел. 4-6 Tb стоят не очень много сейчас + синологи= нормальный домашний сервер.


#4 
wasja-de постоялец03.12.23 23:05
NEW 03.12.23 23:05 
в ответ AlexNek 03.12.23 22:17
может проще micro sd card по почте слать?

я лет 10 назад как раз участвовал в проекте, где данные по почте были. Раз в неделю приходила посылка с двухтерабайтником, или двумя такими дисками, а после обработки, я эти диски назад отправлял. Тогда была иерархия - точка-в-точку, особо не требовало усилий.


А что мешает сделать больше? Буквально на неделе искал хороший 7200 диск, меньше 2 терабайт не нашел. 4-6 Tb стоят не очень много сейчас + синологи= нормальный домашний сервер.


Сейчас данных может быть много. Как я уже писал, есть 50 терабайт, скорей всего будет еще докупаться. И основная проблема не в том, где найти на домашнем сервере столько места, а как не запутанно организовать способ сохранения и бекапов, чтобы команда без простоя работала и не сралась из-за не понимания где есть данные. Технически почти всегда какая-то обработка данных может быть произведена и удаленно, но, грубо говоря, это тоже надо администрить. То есть если кто-то обнаружит, что ему нужные данные есть у меня на лаптопе, качнет свой софт мне, и у меня запустит обработку, а я, не зная, что это произошло, возьму и закрою крышку лаптопа.


Да и качнуть терабайт с одного пользователя другому по домашней сетке может быть сложно хотя бы из-за того, что провайдер может на дыбы встать. А по мобильнику - так совсем. Тем более в Германии, с ужасно плохой инфраструктурой сетей. Я, кстати, несколько лет назад, когда у меня был ужасно медленный интернет, как-то попросил знакомого качнуть где-то 400ГБ на мой сервер, так его проводной провайдер (1&1) ему потом слал кучу макулатуры на подпись, что он не торрентил.

#5 
AlexNek патриот03.12.23 23:19
AlexNek
NEW 03.12.23 23:19 
в ответ wasja-de 03.12.23 23:05
Сейчас данных может быть много

В любом случае их нужно где то хранить в одном месте.

И если по интернету сложно, то остается только физическая пересылка.


как не запутанно организовать способ сохранения

Это будет проблема N1. Что именно хотим хранить? Большие данные или только "ссылки" на них?


и бекапов,

Это будет проблема N2 - почти уверен что под никсами есть полно софта для этого.

https://www.cyberciti.biz/open-source/awesome-backup-softw...

#6 
anatoli888 гость08.12.23 23:07
NEW 08.12.23 23:07 
в ответ wasja-de 03.12.23 11:34
  1. Git-сервер - наше всё! Забиваем на облака, ставим свой GitLab прям на нашем серваке. Контроль версий, задачи, вики – весь пакет. Работаем круто и без шума.
  2. Git на каждом лаптопе: Чтобы каждый был сам по себе хакер, настраиваем локальные репы Git. Оффлайн? Не беда, всё синхронизируем потом.
  3. Docker – наше спасение: Каждый со своими компиляторами, как в зоопарке, но без головняка. Docker на помощь – контейнеры туда-сюда, и всё гладко.
  4. Бекапы? Есть! Берем rsync или что посерьезнее типа Bacula, и настраиваем автомат бекапов на сервер и внешние HDD. Пусть крутится!
  5. Синхронизация – по пацански: В оффлайне? Не вопрос, Wi-Fi сеть в студию, Syncthing и всё такое. Обмениваемся данными, как настоящие гуру.
  6. Шифрование и VPN: Чтобы никто не подсматривал, шифруем данные и ставим VPN. Безопасность превыше всего!
  7. Управление доступом: Кто куда может – строго по списку. Никаких лишних глаз и рук.

Вот такой план, бро. Работаем круто, быстро и без шума. Пацаны в теме! 🤟

вон тебе совет от ChatGPT :)

#7 
alex445 коренной житель09.12.23 02:08
NEW 09.12.23 02:08 
в ответ anatoli888 08.12.23 23:07
  1. Git-сервер - наше всё! Забиваем на облака, ставим свой GitLab прям на нашем серваке. Контроль версий, задачи, вики – весь пакет. Работаем круто и без шума.
  2. Git на каждом лаптопе: Чтобы каждый был сам по себе хакер, настраиваем локальные репы Git. Оффлайн? Не беда, всё синхронизируем потом.
  3. Docker – наше спасение: Каждый со своими компиляторами, как в зоопарке, но без головняка. Docker на помощь – контейнеры туда-сюда, и всё гладко.
  4. Бекапы? Есть! Берем rsync или что посерьезнее типа Bacula, и настраиваем автомат бекапов на сервер и внешние HDD. Пусть крутится!
  5. Синхронизация – по пацански: В оффлайне? Не вопрос, Wi-Fi сеть в студию, Syncthing и всё такое. Обмениваемся данными, как настоящие гуру.
  6. Шифрование и VPN: Чтобы никто не подсматривал, шифруем данные и ставим VPN. Безопасность превыше всего!
  7. Управление доступом: Кто куда может – строго по списку. Никаких лишних глаз и рук.

#8 
alex445 коренной житель12.02.24 21:51
NEW 12.02.24 21:51 
в ответ alex445 09.12.23 02:08, Последний раз изменено 12.02.24 21:55 (alex445)

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


Торвальдс там чем думал, когда такое творил?

#9 
AlexNek патриот12.02.24 22:29
AlexNek
NEW 12.02.24 22:29 
в ответ alex445 12.02.24 21:51
там чем думал, когда такое творил?

правильным местом смущ и желательно подумать отчего именно так сделано.

Может еще нужно разрешить содержимое файлов редактировать в старых коммитах?

#10 
alex445 коренной житель13.02.24 01:10
NEW 13.02.24 01:10 
в ответ AlexNek 12.02.24 22:29

Какой догмат торвальдсовско-линуксовой религии будет нарушен, если можно будет поправить комменты?

#11 
AlexNek патриот13.02.24 18:15
AlexNek
NEW 13.02.24 18:15 
в ответ alex445 13.02.24 01:10
если можно будет поправить комменты?

Давайте начнем немного с другого.

Закомитил я проект и вдруг вижу, что в описании ошибка. Как ее исправить? Нужно видимо отредактировать файл readme в коммите.

Хочу редактировать - фиг вам, низзя - почему?

#12 
Бесконечный цикл постоялец13.02.24 19:09
NEW 13.02.24 19:09 
в ответ wasja-de 03.12.23 11:34

Хранение данных. Совместима с Амазоновским S3 https://github.com/minio/minio


Версионирование данных. https://github.com/iterative/dvc Довольно популярная штука, хотя я не уверен, что это хорошо. Какие-то наши сделали и весной-летом подняли финансирование и искали работников на удаленку.


Обработка данных. https://github.com/ray-project/ray Это просто огонь. Я покурил немного доки и впечатлился. Spark отдыхает. Для обработки и анализа данных. Уже есть на AWS и Azure, хотя относительно новая штука.

#13 
alex445 коренной житель13.02.24 20:37
NEW 13.02.24 20:37 
в ответ AlexNek 13.02.24 18:15
если можно будет поправить комменты?

Давайте начнем немного с другого.

Закомитил я проект и вдруг вижу, что в описании ошибка. Как ее исправить? Нужно видимо отредактировать файл readme в коммите.

Хочу редактировать - фиг вам, низзя - почему?

Вы смешали коммит и его описание. Исправить коммит - это исправить код. Это через другой коммит. А описание коммита это не код. И его должно быть можно исправить без проблем. То, что Торвальдс не разделил это - его недоработка.


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

#14 
AlexNek патриот13.02.24 21:43
AlexNek
NEW 13.02.24 21:43 
в ответ alex445 13.02.24 20:37
коммент относится к коммиту

вот именно! Это и есть концепт.


И представьте, что коммент - это специальный невидимый файл в коммите.


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

1й чел. забрал и отредактировал.

2й чел. забрал и отредактировал тот же коммент.

Какие нужны будут операции на сервере, когда оба захотят сохранить...


#15 
alex445 коренной житель13.02.24 22:47
NEW 13.02.24 22:47 
в ответ AlexNek 13.02.24 21:43, Последний раз изменено 13.02.24 22:49 (alex445)
представьте, что коммент - это специальный невидимый файл в коммите.

Какая разница, как это сейчас реализовано? Главное, как нужно было. Торвальдс недоработал. "Мы не можем это сделать - у нас реализация не позволяет". Ну так сделай, чтобы позволяла. Или нимб над головой мешает, а личные, персональные фанаты и не сильно требуют?


Если очень хочется можно представить, что будет если разрешить редактировать любой коммент.
1й чел. забрал и отредактировал.
2й чел. забрал и отредактировал тот же коммент.
Какие нужны будут операции на сервере, когда оба захотят сохранить...

Вопросы синхронизации человечество решило уже давным давно. Как и вопросы прав доступа. Или Торвальдс недоработал и тут?

#16 
Программист коренной житель14.02.24 10:00
NEW 14.02.24 10:00 
в ответ alex445 13.02.24 20:37
А что, править коммент коммита можно только через другой коммит? А как? Делать пустой коммит с правильным комментом? Это же чушь - коммент относится к коммиту, т.к. комментирует то, что сделано в коммите.

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

Так сказать "написаное пером не вырубить топором". И если человек хочет внести какие-то изменения, то ему предоставили способ эти изменения сделать. Но при этом должно быть видно, что были изменения.

#17 
alex445 коренной житель14.02.24 15:30
NEW 14.02.24 15:30 
в ответ Программист 14.02.24 10:00, Последний раз изменено 14.02.24 15:31 (alex445)
Концепт предельно прост - все, что сохраняется не может быть изменено.

Я и говорю - сделано на отъебись, proof of concept, не подумав дальше носа. А потом забронзовело, как и создатель этого. )))

#18 
MrSanders коренной житель14.02.24 15:56
NEW 14.02.24 15:56 
в ответ alex445 14.02.24 15:30

Так это, сделай свой. Кто ж тебя останавливает, ты погромизд или где?

P.S. учи яву, как выучишь, я тебя на работу пристрою - у тебя счастье будет. Там половина команды такие же.

#19 
AlexNek патриот14.02.24 18:17
AlexNek
NEW 14.02.24 18:17 
в ответ alex445 13.02.24 22:47
Главное, как нужно было.

Сделано именно так как нужно.

А то, что кому то хочется по другому...

Вроде бы казалось, концепт понятен стал, но нет - разработчик придурок.


Вопросы синхронизации человечество решило уже давным давно.

Интересно, поделитесь знаниями. Как конкретно будем синхронизировать изменения одного и того же коммента от разных людей?

#20 
1 2 3 все