git-annex - Công cụ quản lý tệp dung lượng lớn dành cho người dùng Git

• git-annex là công cụ giúp quản lý các tệp lớn mà không cần đưa trực tiếp nội dung của chúng vào kho Git
• Hỗ trợ đồng bộ, sao lưu, lưu trữ trong cả môi trường offline lẫn online, đồng thời đảm bảo an toàn bằng checksum và mã hóa
• Áp dụng đặc tính phân tán của Git cho tệp dung lượng lớn, giúp đơn giản hóa việc theo dõi vị trí và truyền tải giữa nhiều ổ đĩa, máy chủ và đám mây
• Phù hợp với người dùng thiên về CLI, đồng thời git-annex assistant mang lại trải nghiệm sử dụng kiểu đồng bộ thư mục cho người dùng phổ thông
• Là công cụ mở rộng quy trình lưu trữ và di chuyển dữ liệu thông qua định dạng repository đơn giản phục vụ bảo quản dài hạn và nhiều special remotes khác nhau

---

Tổng quan

• git-annex là công cụ quản lý tệp dung lượng lớn theo cách giữ nội dung tệp ở ngoài Git, còn chỉ quản lý metadata và thông tin vị trí bằng Git
  • Nhờ đó lịch sử commit vẫn gọn nhẹ, trong khi việc lưu trữ và di chuyển các tệp nhị phân lớn trở nên linh hoạt hơn
  • Hỗ trợ checksum và mã hóa để đảm bảo tính toàn vẹn và tính bảo mật
• Hỗ trợ đồng bộ, sao lưu, lưu trữ trong cả môi trường offline lẫn online, đồng thời cung cấp khả năng quản lý số lượng bản sao của cùng một tệp giữa các kho lưu trữ phân tán và ghi log
• Được tối ưu cho người dùng dòng lệnh, nhưng người dùng phổ thông cũng có thể dễ dàng sử dụng theo kiểu đồng bộ thư mục thông qua git-annex assistant
• Cung cấp tài liệu walkthrough cho người mới để nhanh chóng học cách cài đặt và quy trình cơ bản

Trường hợp sử dụng: Archivist (người dùng thiên về lưu trữ)

• Có thể vận hành nhiều ổ đĩa lưu trữ offline nhưng vẫn duyệt và tái tổ chức toàn bộ tệp như thể chúng nằm trong một cây thư mục duy nhất
  • Ngay cả khi nội dung tệp nằm trên ổ đĩa offline, vẫn có thể di chuyển và commit thông qua chỉ mục và con trỏ mà không có nguy cơ xóa nhầm dữ liệu thực tế
• Khi cần một tệp cụ thể, công cụ cho biết tệp đó đang nằm trên ổ nào và có thể dễ dàng đưa nó về trạng thái sẵn sàng sử dụng
  • Mỗi ổ đĩa chia sẻ thông tin vị trí lẫn nhau để giúp nắm được toàn cảnh tình trạng lưu trữ
• Sử dụng định dạng repository đơn giản nên ngay cả khi không dùng git-annex hay git, khả năng truy cập tệp về lâu dài vẫn được duy trì
• Có thể dùng tác vụ cron để tự động lưu trữ các tệp mới vào ban đêm, đồng thời ghi lại các bản sao có chủ đích hoặc vô tình để làm căn cứ xác định khi nào cần nhân bản thêm

Trường hợp sử dụng: Nomad (người dùng thiên về di chuyển)

• Có thể quản lý nhất quán các kho lưu trữ dị thể như laptop, ổ USB/USB key di động, máy chủ từ xa và kho lưu trữ đám mây mã hóa theo cách giống như Git remote
  • Khi đang di chuyển, có thể xếp hàng đợi tải xuống trên máy chủ và thực hiện truyền dữ liệu thực tế sau đó ở nơi có kết nối tốt hơn, tức là hỗ trợ quy trình truyền trì hoãn
• Cũng có thể xây dựng workflow thân thiện với offline như sao chép tức thời từ USB rồi sử dụng cục bộ để tiết kiệm pin
• Sau khi dùng xong, nếu chỉ định những gì cần giữ hoặc xóa, có thể thu hồi dung lượng cục bộ và đồng bộ các thay đổi với máy chủ ở lần đồng bộ tiếp theo
• Thông qua special remotes và pipeline truyền tải, công cụ cho phép di chuyển dữ liệu linh hoạt trong nhiều backend lưu trữ và điều kiện mạng khác nhau

Tính năng và lợi ích cốt lõi

• Đảm bảo tính toàn vẹn dựa trên content addressing và checksum, đồng thời hỗ trợ lưu trữ mã hóa để hiện thực hóa việc bảo quản an toàn dài hạn
• Thông qua theo dõi vị trí (location tracking), có thể nắm rõ vị trí lưu trữ, số lượng bản sao và mức độ sẵn sàng của từng tệp
• Áp dụng mô hình quản lý phiên bản phân tán cho tệp dung lượng lớn để giảm phụ thuộc vào lưu trữ tập trung và tăng khả năng chống chịu khi offline
• Chế độ assistant mang lại trải nghiệm đồng bộ thư mục, giúp cả người không quen CLI cũng có được mức tiện dụng gần như kéo-thả

Tóm tắt ưu điểm

• git-annex chỉ quản lý tham chiếu tệp bằng git, vì vậy rất phù hợp để xử lý các tệp dung lượng lớn mà không tạo gánh nặng
• Với kiến trúc phân tán, có thể tự do di chuyển, lưu trữ, đồng bộ/sao lưu và quản lý phiên bản tệp giữa nhiều thiết bị và địa điểm
• Đặc biệt có tính tích hợp và khả năng mở rộng cao cho các kịch bản offline, lưu trữ dài hạn hoặc quản lý dữ liệu linh hoạt giữa nhiều thiết bị và đám mây
• Phù hợp cả với người dùng kết hợp giữa định hướng lưu trữ và định hướng di chuyển, đồng thời hữu ích cho cả tổ chức lẫn cá nhân nhờ quản lý chính sách bản sao và đa dạng hóa backend
• Là công cụ mở rộng tính phân tán và tính di động của Git sang dữ liệu dung lượng lớn, từ đó giảm rủi ro vận hành và công sức trong các tác vụ lưu trữ dài hạn và di chuyển dữ liệu

[GN⁺]

Ý kiến trên Hacker News

• Tôi dùng git-annex để quản lý dữ liệu trên mọi ổ đĩa. Nó tự động theo dõi mỗi tệp nằm ở ổ nào, giữ đủ số lượng bản sao, và kiểm tra checksum cho toàn bộ tệp. Nó cũng hoạt động tốt với cả các ổ đang offline. git-annex lúc đầu có thể hơi khó nắm bắt, nên tôi khuyên nên tạo một kho tạm rồi làm theo walkthrough để thực hành. Ngoài ra cũng đáng tham khảo các workflow khác nhau

  • Tôi tò mò bạn đang lưu trữ bao nhiêu dữ liệu. Tôi đang quản lý khoảng 100 nghìn đến 1 triệu tệp, vài TB dữ liệu ảnh trên ZFS bằng git-annex. Ban đầu không có vấn đề gì, nhưng gần đây nó ngày càng chậm, đến mức mỗi lệnh mất 5–30 phút. Tôi không rõ là do ZFS, git-annex hay do đĩa

  • Tôi từng nghĩ đến việc quản lý dữ liệu bằng git-annex từ lâu, nhưng gặp một số vấn đề, trong đó có sự bất tiện khi xóa tệp hoàn toàn. Nếu có thời gian, tôi muốn hỏi liệu bạn có thể chia sẻ cách bạn đang dùng nó không

• Dù trên trang không hiện ra, git-annex do Joey Hess tạo ra. Ông ấy cũng phát triển moreutils, etckeeper

  • Với cá nhân tôi, điều nổi tiếng hơn là ông ấy đã là một người đóng góp nòng cốt cho Debian suốt nhiều thập kỷ kể từ năm 1996. Một phần lớn của Linux như chúng ta biết ngày nay đã đi ra từ tay ông ấy

• Gần đây đã có thảo luận về tính năng quản lý object lớn native mới của Git ở đây

  • Nói thêm, tôi cũng đã giải thích trong bình luận vì sao tôi cho rằng cuộc thảo luận đó không liên quan nhiều. annex thực ra thuộc một phạm vi hơi khác so với bài toán “tệp lớn trong git”. Có thể dễ hiểu git-annex hơn nếu xem nó như cách phân tán theo kiểu native của git cho bài toán lưu trữ “phía máy chủ” mà LFS và các công cụ tương tự xử lý

• Điểm đáng tiếc ở git-annex là Haskell. Không phải tôi ghét ngôn ngữ này, nhưng tôi thực sự ngạc nhiên vì số lượng dependency phải cài quá nhiều. Phần lớn trong số đó lại không cần ở nơi khác, và còn dễ phát sinh xung đột phiên bản giữa nhiều ứng dụng. Cài bằng trình quản lý gói của hệ thống thì đặc biệt vất vả. Chỉ cài annex và pandoc thôi mà mỗi ngày đã có hàng chục cập nhật gói Haskell. Nếu dùng distro build từ source thì đúng là ác mộng. Tôi thật ra nghĩ phần lớn có thể static link an toàn. Thế nhưng phía Haskell lại cho rằng đây là hệ quả của việc mô-đun hóa thư viện rất nhỏ. Nhưng còn có các ưu tiên khác như quản trị hệ thống, và tôi chưa từng gặp chuyện này với Rust, Go, Zig, C hay C++. Tôi không có ác cảm với hệ sinh thái hay người dùng Haskell, tôi thậm chí còn định học nó. Nhưng tôi muốn biết vì sao vấn đề này tồn tại và giải pháp là gì

  • Tooling của Haskell đã hỗ trợ static linking rồi. Tôi quản lý stack Haskell cho Solus, và pandoc chỉ phụ thuộc vào libc, còn mọi gói Haskell đều được nhúng tĩnh vào binary để phát hành giống hệt Rust. Nghĩa là hoàn toàn làm được. Trên Solus, vì dependency quá nhiều nên chúng tôi cứ dùng static linking. Tôi nghĩ đây là vấn đề do quyết định của người bảo trì distro

  • Về đoạn “phần lớn có thể static link an toàn”, nếu là trong repo của distro thì rốt cuộc chẳng phải đây là vấn đề chính sách của trình quản lý gói sao?

  • Ngay cả với tư cách là một lập trình viên Haskell toàn thời gian, tôi cũng có cảm giác e ngại tương tự với các gói Haskell không được static link. Trên AUR đã có các bản static-linked, nên ít nhất chuyện đó không phải là bất khả thi. Tôi cũng chưa thực sự đào sâu xem vì sao các packager lại cứ khăng khăng dùng dynamic linking. Nhìn chung dynamic linking có thể hợp với phân phối phần mềm nội bộ, nhưng có lẽ họ đang áp dụng điều đó lên distro một cách không cần thiết

  • Tôi tò mò bạn dùng trình quản lý gói nào. Trên các hệ apt, tôi chưa từng gặp rắc rối nào do Haskell

  • Mỗi lần pacman -Syu thì một nửa số bản cập nhật là gói Haskell nên rất bực. Có lẽ thủ phạm là pandoc hoặc shellcheck

• git-annex là công nghệ thực sự rất ngầu. Nhưng ấn tượng của tôi là nó hoạt động tốt nhất trong kho của một người dùng duy nhất. Chẳng hạn một người quản lý dữ liệu cá nhân của mình như tệp, tài liệu, nhạc trên nhiều thiết bị khác nhau. Tôi đã thử dùng nó để đồng bộ trong kho cộng tác có tệp lớn, nhưng cách dùng nhánh “magic” không mở rộng tốt

  • Điều này có thể khác tùy người, nhưng ở tổ chức của chúng tôi thì ngược lại, nó hoạt động tốt. Chúng tôi là một đơn vị lưu trữ số, và đã dùng git-annex làm backend cho kho nội bộ hơn 10 năm. Nhân sự khoảng 15–20 người, nhưng vẫn xử lý ổn hơn 30TB dữ liệu và 750 nghìn tệp (nhị phân + metadata), trải trên hàng trăm kho

• Tôi đang dùng forgejo tự host. Tôi vẫn chưa thấy git-annex vượt LFS ở điểm nào, mà có vẻ thiết lập cũng không dễ. Tôi cũng không thích việc git-annex được viết bằng Haskell, và còn thấy nói nó chậm hơn khoảng 50% nữa (dù chỉ thấy một nguồn nên chưa rõ có đáng tin không). Chắc hẳn có lý do khiến lệnh của nó phức tạp, nhưng nó không có sự tiện lợi kiểu chỉ cần chỉnh .gitattributes là gần như hiểu hết mọi thứ như LFS. Tôi cũng không thấy git-annex có mức độ minh bạch tương tự .gitattributes. Và nếu tutorial còn không chỉ ra lệnh tương đương với 'git lfs ls-files' thì có lẽ tôi khó mà hứng thú. Tôi có thói quen kiểm tra bằng 'git status' và 'git lfs ls-files'

  • Chậm không phải vì Haskell. git-annex là công cụ backup phân tán, nên cái gây chậm là các thao tác thiên nặng về I/O và cực kỳ khắt khe với việc bảo toàn dữ liệu. Ví dụ khi dùng lệnh drop, nó phải kiểm tra theo thời gian thực xem nội dung đó có tồn tại trên mọi remote hay không, nên chậm. Nếu dùng tùy chọn như --fast để chỉ tin metadata cục bộ và bỏ qua bước xác minh thì sẽ nhanh hơn nhiều (nhưng hơi rủi ro)

  • LFS và git-annex phục vụ mục đích hơi khác nhau. LFS phù hợp với các ví dụ phát triển có trộn tệp lớn trong kho git, như làm game chẳng hạn. git-annex hợp hơn khi bạn muốn backup dữ liệu quan trọng, hoặc lưu nhiều bộ tệp lớn như thư mục nhạc ở nhiều nơi. Tôi dùng nó theo kiểu thứ hai

  • Có một soft-fork của Forgejo hỗ trợ git-annex: forgejo-aneksajo

  • Kho lớn nhất tôi quản lý bằng git-annex là cỡ vài TB, phân tán trên nhiều hệ thống, với khá nhiều tệp lớn hơn 10GB. Nếu điều tác giả muốn là tương đương git-lfs-ls-files, thì trong git-annex có lẽ git annex list --in here đóng vai trò tương tự

• Việc tài liệu dòng lệnh đưa các trường hợp sử dụng thực tế lên đầu cho thấy một mức độ tận tâm đáng quý. Nhiều công cụ thường mở đầu bằng mô tả các tùy chọn khó hiểu mà gần như chẳng ai dùng, nên khá đáng tiếc

• GitHub đã áp dụng kiểu NIH (Not Invented Here) của Microsoft với LFS và không tiếp nhận git-annex

  • Tôi cũng nghĩ git-annex thanh lịch hơn, nhưng khả năng tương thích đa nền tảng của nó yếu hơn. Nhân tiện, LFS xuất phát từ sự hợp tác giữa GitHub và Bitbucket (chính xác là forge nào thì tôi không còn nhớ). Một bên làm implementation, một bên đưa ra cái tên, rồi họ gặp nhau ở một hội nghị Git và gộp lại. Điều khiến tôi thất vọng nhất hiện nay là các giới hạn áp lên dự án lớn trên GitHub. Thêm nữa, chính sách “phải kéo toàn bộ object về local mới được push” khiến các cộng đồng phát triển có quy mô rất nhanh chóng chạm trần. Tiện nói luôn: tôi từng đóng góp cho git-lfs

  • (Nói thật) cách tiếp cận NIH của GitHub là một bất lợi trên mọi phương diện. Có một bài thuyết trình của một người rất mê git-annex: Staying in Control of your Scientific Data with Git Annex by Yann Büchau

• Trớ trêu là cuối tuần trước tôi đã dành một ngày để tự làm hệ thống versioning tệp lớn của riêng mình. Tôi ghét git-annex đến mức đó. Nó biến tệp thành blob và làm phình hệ thống tệp. Mục tiêu chính của tôi là đồng bộ giữa các tệp phân tán, chứ không quan tâm đến versioning bản thân chúng (thật sự tôi không hiểu vì sao lại cần versioning cho tệp lớn). Với AI và Python, bạn có thể băm tệp để tạo bảng tra cứu, rồi viết các helper method dùng rclone để đồng bộ nguồn. Có rất nhiều cách đơn giản và hiệu quả hơn nhiều

• Tôi đã dùng nó qua nhiều năm, và ưu điểm lớn nhất là tích hợp với nhà cung cấp cloud storage và backup. Nhưng các tính năng tích hợp đó luôn có vẻ thiếu ổn định và phụ thuộc vào plugin bên thứ ba không được duy trì. Đã từng có bug gây lệch dữ liệu nên cuối cùng tôi bỏ cuộc. Tôi tò mò không biết trong 5 năm gần đây có cải thiện gì không

  • Tôi nghĩ điều đó tùy vào loại nhà cung cấp cloud storage. Những nơi hỗ trợ các giao thức chuẩn chính thức như S3, webdav, sftp sẽ thuận lợi hơn. Gần đây git-annex đã tích hợp special remote dựa trên rclone, cái này được bảo trì tốt hơn các remote bên thứ ba trước đây và có thể kết nối với gần như mọi cloud remote mà rclone hỗ trợ