Как сделать свой собственный сервер Dropbox / Ubuntu One дома?

На самом деле их много.

• SparkleShare (deps: git / subversion, mono, python) в программном обеспечении синхронизации на основе github.

  а. Управление версиями: через систему контроля версий, следовательно, оно основано на мьютексе на центральном сервере через номер версии.

  б. Состояние: в разработке

  с. Плюсы: OSS, монофонический, так легко модифицируемый, Минусы: процесс на уровне пользователя, GC-зависимый, неэффективный протокол совместного использования на порядки, поскольку git в основном предназначен для небольших текстовых файлов, довольно сложно компилировать (я пытался). Использование инструментов высокого уровня.

• lipsync (deps: Unison, rsync) Программное обеспечение на основе командной строки.

  а. Управление версиями: через алгоритм rsync delta. Я предполагаю, что программист должен выбрать разрешение конфликта.

  б. Состояние: я не могу найти его исходный код, поэтому понятия не имею. Единственные вещи в его git-репо - это двоичные файлы.

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

• iFolder - Dropbox от Novell. Я еще не изучал его источник. Я просто хочу закончить это редактирование, и если людям будет интересно, я добавлю больше.

  а. Versioning:

  б. Состояние: проблематично заставить его компилироваться даже в Ubuntu, не говоря уже о пакетах. Вот подробное руководство по установке.

  с. Плюсы: клиент Windows X64, зрелый, AD-интеграция с ACL, функции, которые еще ни один проект не начал реализовывать. Я думаю, что это может быть хорошей отправной точкой. Минусы: Novell может не использовать свое общедоступное репозиторий SVN в качестве основного репо, а только выполнять удаление кода. Хотя я точно не знаю об этом. Возможно, он слишком связан с openSUSE, чтобы его можно было легко установить в Ubuntu. Чтобы проверить его алгоритмы.

• scp / rcp - устарел в пользу rsync

• DRDB - блочные средства зеркалирования устройств для распределенного RAID-1, то есть серверный вариант Dropbox. Я еще не проверил его исходный код, но это только Linux. Реальный алгоритм, вероятно, будет легко объединить с исходным кодом в моих рассуждениях ниже этого списка программного обеспечения.

  а. Управление версиями: внутренний формат сообщения через LAN/WAN

  б. Состояние: кажется достаточно зрелым

  с. Плюсы: достаточно стабильно для Linux, Минусы: другие операционные системы не поддерживаются.

Сейчас я изучаю вопрос улучшения времени компиляции в виртуализированной Windows 7, где время компиляции в Windows 7 на металле составляет 40 с, а в виртуализации - около 3 м 20 с. Я подумываю о написании драйвера ioctl, который представляет собой сквозной кэш, который выглядит как ram-диск для выбранных папок в NTFS.

Используя вышеупомянутое программное обеспечение, я думаю, что недельная разработка из 2-3 человек с полной занятостью создаст полезную Альфу, которая не потеряет ваши файлы при объединении вышеуказанных программ.

В моей системе общая идея была бы такой:

1. Смонтируйте виртуальный диск \?{GUID}, то есть ram-диск и RW-кеш. Программное обеспечение, создающее этот виртуальный диск, принимает два входных параметра (которые являются жизненно важными):

   а. Целевая папка; это папка SMB, поэтому я позволю сетевому стеку операционной системы обрабатывать фактический ввод-вывод. В моем случае это, в свою очередь, виртуальная папка VMWare, которая сама по себе имеет цель на диске ext4, но это может быть ваш файловый сервер, использующий SAMBA/SMB.

   б. Путь к папке для монтирования, например, C:\ramdisk

   Этот код для создания виртуальных томов можно взять из кода TrueCrypt, в /Driver/DriverFilter.c (среди других файлов)

2. Привод использует SMB/ VMWare/ сетевой протокол для извлечения данных при запуске; он выбирает с низким приоритетом задачи, асинхронно из сети и заполняет свой кэш. Он может использовать простой алгоритм сжатия и иметь 1 поток, который использует передачу продолжения типа окна сообщения для получения высокой производительности. В Windows он может использовать обычные асинхронные вызовы ввода-вывода, а в Linux он может использовать реализацию epoll/ inotify и получать код из nginx.

3. Мой сервис, который является ram-disk, монтирует неназванный диск ramdisk как папку NTFS. Все программы могут продолжать запись в C:\ramdisk или как я его называю.

4. Асинхронное копирование из сети все еще продолжается. При скорости чтения около 100 МБ / с и виртуальном диске 2 ГБ чтение всех данных составит 20,5 с.

Каждый вызов read будет выполнять вычисление индекса внутри процессора в фиксированный массив максимального размера n: ulong GiB. Это потребует разрешения конфликтов или блокировки чтения-записи. Если бы мы внедрили алгоритм разрешения конфликтов, подобный тому, который доступен через Microsoft Sync, мы могли бы передать каждый конфликтующий фрагмент как сообщение другому процессу разрешения конфликтов. Dropbox решает его, создав новый файл и назвав его "Конфликтующая копия имени пользователя PrevFileName (yyyy-MM-dd).ext". Возможно, это можно изменить с помощью небольшого виджета, если он компилируется с этим единственным источником - виджет будет обнаруживать выдающиеся изменения как сообщения / события и выбирать протокол разрешения конфликтов. Таким образом, при программировании для папки в монопольном режиме виртуальная машина Windows может установить виджет "эксклюзивный".

Это будет иметь эти PRO

• Это было бы неблокирующим / асинхронным
• Это сделало бы предположение, но не требовало бы, чтобы один компьютер записывал в основном файлы.
• Это будет работать для произвольно больших файлов
• Он будет работать на * nix и Windows, связывая вместе упомянутые проекты.
• Это будет работать, когда требуется высокая производительность чтения (т.е. файлы физически расположены на диске)
• Когда достигаются конфликтующие события, можно предоставить приложение пользовательского интерфейса, которое позволяет пользователю писать / загружать плагины, которые действуют разумно для разных видов событий, то есть для разных типов файлов. Например, текстовый файл можно вызвать с помощью Kompare/WinDiff, а двоичный файл будет продублирован и сохранен как другой файл.

OwnCloud! звучит как то, что вы ищете.

Я слышал о Syncany на подкасте Ubuntu UK, в настоящее время бета, но похоже, что он соответствует требованиям

Я не думаю, что это именно то, что вы ищете, но это зависит от вашего предполагаемого использования.

CrashPlan - это пакет программного обеспечения для резервного копирования и связанная с ним услуга онлайн-хостинга резервного копирования, но отличается тем, что в его программном обеспечении есть режим, позволяющий выполнять резервное копирование данных через Интернет (или ЛВС) на другой ПК, на котором запущено программное обеспечение.

Это означает, что пункт назначения не должен быть в облаке. Это не совсем похоже на Dropbox, так как речь идет скорее о резервном копировании, а не о синхронизации и доступе к файлам из любого места, но если вам нужны только резервные копии, то это работает хорошо. Если вы хотите получить доступ к файлам резервных копий с другого компьютера, я думаю, вы можете выполнить "локальное восстановление", но я не пытался это сделать.

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

Я использую Unison для клиента и http://rsnapshot.org/ (rsync со скриптом perl) для резервного копирования сервера.

Если вы хотите настроить две (или более) машины с реплицированной папкой, взгляните на glusterfs.

Это легко настроить, если вы будете следовать Руководству пользователя GlusterFS.

Посмотрите, поможет ли это:

http://fak3r.com/2009/09/14/howto-build-your-own-open-source-dropbox-clone/

Никто не упомянул биторрентную синхронизацию? Работает на чем угодно - Ubuntu, Windows, многие распространенные ОС для смартфонов, Raspberry Pi.... Вы называете это, это, вероятно, работает, и как обычный пользователь. Зашифрованные передачи, файлы не хранятся в облаке (хотя я думаю, что bittorrent запускает трекер для него), достаточно быстро, вы можете выборочно обмениваться папками, и почти без сложностей, вам просто нужно скопировать и вставить ключ в другой система.

Как только это настроено, это просто работает.

Я использую apache с mod_dav (webdav) для веб-сервера apache, я могу смонтировать его как диск и загружать / скачивать файлы через Интернет. Это довольно просто, но может удовлетворить ваши потребности.

Хотя здесь уже есть интересные альтернативы, и это более старый вопрос, я убежден, что эта тема явно не устарела и, наоборот, приобретает все большее значение в связи с последними событиями, нарушающими конфиденциальность.

Поэтому я хочу поделиться своим собственным опытом. Мое текущее решение для собственной облачной среды - Seafile.

Особенности Seafile:

• Облачный веб-доступ
• Клиенты для Linux, Windows, Mac, iOS (не бесплатно), Android
• Управление пользователями / группами
• Организация файлов через разные библиотеки
• Автоматическая синхронизация файлов через клиентское программное обеспечение
• Возможность публикации файлов через создание публичных ссылок

Мой опыт Seafile:

• Установка была невероятно простой и быстрой! (на тонком Debian VM, файлы хранятся через общий ресурс на физическом хосте dmraid 5)
• Пользовательский интерфейс чистый и функциональный
• Клиентское программное обеспечение чистое и функциональное
• У меня не было никаких функциональных проблем, до сих пор! (используя это уже несколько недель)
• Набор функций является базовым (например, по сравнению с owncloud), но я подчеркиваю, что здесь все работает!
• Нет прямой поддержки прокси (по крайней мере, для клиента Linux - и веб-интерфейс!). Примечание: веб-интерфейс работает, но загрузка файлов через веб-интерфейс не работает через прокси-сервер - не знаю, возможно ли это как-то

Поскольку мне не нужна поддержка прокси, я очень доволен Seafile!

Я слежу за AeroFS. Похоже, что это может быть Dropbox-подобный сервис, где хранение в облаке не является обязательным. Не знаю, если / когда они будут реализовывать мобильную поддержку, и я предполагаю, что для этого потребуется синхронизировать эти файлы с облаком. В первую очередь меня интересует довольно безболезненное решение для синхронизации между компьютерами Windows, Mac и Linux.

Они в ранней бета-версии, но вы можете подписаться на приглашение, если хотите.

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

Это очень прямо и просто, и я считаю, что это лучшее решение. Единственное, для чего я не использую это большие медиа, такие как картинки и фильмы, потому что все файлы доступны по сети. Те, которые я синхронизирую с Rsync.

Ссылка на документацию SSHFS -> http://fuse.sourceforge.net/sshfs.html