Hugging Face repo کا قابلِ بحالی backup کیسے بنائیں

Hugging Face repository کا قابلِ بحالی backup بنانے کے لیے کسی branch کے بجائے پورا commit SHA منتخب کریں اور اسی revision کو الگ مقامی directory میں download کریں۔ اگر branches، tags اور پرانے commits بھی واپس لانے ہیں تو snapshot کے ساتھ Git history اور متعلقہ large-file objects محفوظ کرنا ضروری ہے؛ صرف موجودہ cache نقل کرنا مکمل backup نہیں بنتا۔

کم از کم قابلِ استعمال package میں pinned snapshot، repo ID اور revision والا manifest، SHA-256 checksums اور offline restore test شامل ہونا چاہیے۔ محدود bandwidth میں منتخب weights محفوظ کیے جاسکتے ہیں، مگر ایسی نقل کو صاف طور پر filtered backup لکھیں تاکہ بعد میں اسے مکمل repository نہ سمجھ لیا جائے۔

پہلے revision اور backup کی حد طے کریں

متعین commit SHA کے ساتھ Hugging Face repository کی منظم مقامی snapshot

main یا کوئی دوسری branch وقت کے ساتھ نئے commit کی طرف منتقل ہوسکتی ہے، اس لیے reproducible snapshot کے لیے مکمل commit SHA درج کریں۔ Repository کی commit history سے SHA لیں، یا model_info، dataset_info یا space_info سے ملنے والی sha value محفوظ کریں۔

متعین revision کی portable directory بنانے کے لیے hf download org/repo --revision COMMIT_SHA --local-dir /backups/org--repo/COMMIT_SHA چلائیں۔ Dataset کے لیے hf download hf://datasets/org/repo@COMMIT_SHA --local-dir /backups/org--repo/COMMIT_SHA اور Space کے لیے URI میں spaces استعمال کریں۔ Private یا gated repo کی صورت میں مجاز account سے login کریں، مگر access token کو archive یا manifest میں نہ رکھیں۔

Hugging Face کی download guide پورے repository snapshot کے لیے snapshot_download، مقررہ revision کے لیے full-length commit hash اور اصل file structure برقرار رکھنے کے لیے local_dir کی تصدیق کرتی ہے۔ اسی directory میں بننے والا .cache/huggingface folder صرف download metadata رکھتا ہے اور مکمل download کے بعد حذف کیا جاسکتا ہے؛ اصل payload اس کے باہر رہتا ہے۔

تین ضرورتوں کا command matrix

branches، tags اور large-file objects سمیت Hugging Face repo کی مکمل Git نقل

Exact revision snapshot: deployment یا evaluation میں عین وہی files دوبارہ استعمال کرنے کے لیے pinned SHA کے ساتھ hf download یا snapshot_download چلائیں۔ نتیجہ ایک commit کی working copy ہوگا، Git کی پوری تاریخ نہیں۔
مکمل Git history: git clone --mirror https://huggingface.co/org/repo /backups/org--repo.git چلائیں، پھر mirror کے اندر git lfs fetch --all origin استعمال کریں۔ Mirror branches، tags اور commits رکھتا ہے؛ دوسری command ان revisions سے وابستہ LFS objects حاصل کرتی ہے۔
Filtered weights: مثال کے طور پر hf download org/repo --revision COMMIT_SHA --include "*.safetensors" --include "*.json" --include "tokenizer*" --include "*.py" --local-dir /backups/filtered چلائیں۔ اس سے bandwidth اور storage بچ سکتے ہیں، لیکن خارج کی گئی formats manifest میں درج کرنا ہوں گی۔

Filtered model میں تمام weight shards، ان کا index JSON، configuration، tokenizer assets اور inference کے لیے درکار custom code شامل کریں۔ اگر runtime کو ONNX، GGUF یا کسی framework کی مخصوص files درکار ہیں تو patterns اسی حقیقی dependency set کے مطابق بدلیں؛ صرف extension دیکھ کر files خارج کرنے سے restore نامکمل رہ سکتا ہے۔

Cache کیوں مکمل backup نہیں

Hub cache پہلے مانگی گئی files کو دوبارہ download ہونے سے بچاتا ہے۔ اس میں content-addressed blobs، references اور commit-specific snapshots ہوسکتے ہیں، مگر کسی مشین کے cache میں صرف وہ revisions اور files موجود ہوں گی جو اس مشین نے حقیقتاً حاصل کی ہیں۔

اسی لیے بڑی cache directory بھی نامکمل ہوسکتی ہے: کسی اور framework کے weights، dataset shard، Space asset یا پرانا commit کبھی download ہی نہ ہوا ہو۔ Cache کو bandwidth بچانے والی اضافی copy سمجھیں؛ disaster-recovery artifact کو pinned local_dir، manifest اور checksums کے ساتھ الگ archive میں رکھیں۔

Storage estimate اور checksum بنائیں

SHA-256 manifest سے بحال شدہ Hugging Face فائلوں کی سالمیت کی تصدیق

Download سے پہلے hf download org/repo --revision COMMIT_SHA --dry-run چلائیں۔ یہ منتخب repository files اور download ہونے والے bytes دکھاتا ہے؛ filtered copy کے لیے وہی --include یا --exclude options dry run میں بھی دیں۔ یہ موجودہ snapshot کا تخمینہ ہے، پورے Git/LFS history کا نہیں، کیونکہ تاریخ میں تبدیل یا حذف شدہ بڑے objects بھی شامل ہوسکتے ہیں۔

Download کے بعد du -sh /backups/org--repo/COMMIT_SHA سے حقیقی disk usage manifest میں لکھیں۔ اگر snapshot، Git mirror اور archive عارضی طور پر ایک ہی disk پر رہیں گے تو تینوں کے لیے جگہ الگ رکھیں؛ compressed archive بننے تک source directory بھی موجود رہے گی۔

اگر .cache/huggingface metadata آئندہ incremental download کے لیے مطلوب نہیں تو اسے نکالنے کے بعد snapshot کی جڑ میں find . -type f ! -name SHA256SUMS -print0 | sort -z | xargs -0 sha256sum > SHA256SUMS چلائیں۔ پھر sha256sum -c SHA256SUMS سے verification کریں اور ایک copy ایسی storage پر رکھیں جو اصل workstation یا lab server کے failure سے متاثر نہ ہو۔

Git history، Hub copy اور Space کی حدود

Hugging Face کی repository documentation کے مطابق Hub repositories Git repositories ہیں اور git clone درست طریقہ ہے، لیکن مختلف frameworks کے بڑے model weights مقامی حجم بہت بڑھا سکتے ہیں۔ اسی documentation میں server-side copy کو ایک storage region تک محدود کیا گیا ہے؛ دوسری Hub repository مفید نقل ہوسکتی ہے، مگر اکیلی آزاد مقامی backup نہیں۔

Space repository کا Git یا snapshot backup committed code اور assets محفوظ کرتا ہے، مگر hardware، sleep-time، persistent storage، variables اور secrets الگ settings ہیں۔ ان کی inventory علیحدہ رکھیں، secret values کو منظور شدہ secrets manager میں محفوظ کریں اور manifest میں صرف secret names اور بحالی کی ذمہ داری درج کریں۔

حالیہ ownership خبر backup کی operational وجہ کو نہیں بدلتی۔ NVIDIA کے 3 ستمبر 2026 کے اعلان میں Hugging Face خریدنے پر اتفاق اور platform کو open رکھنے کا بیان ہے؛ یہ مکمل شدہ acquisition، outage، repository deletion یا فوری migration کا اعلان نہیں۔

Restore rehearsal سے backup ثابت کریں

Archive کو نئی عارضی directory یا دوسری مشین پر extract کریں اور sha256sum -c SHA256SUMS چلائیں۔ Missing یا changed file ملنے پر اس artifact کو کامیاب backup قرار نہ دیں۔
Model کو local path سے network access بند کرکے load کریں؛ Transformers loader موزوں ہو تو local_files_only=True رکھیں۔ Dataset کے representative sample یا Space کے اصل entry point کے ساتھ dependency lockfile بھی آزمائیں۔
Git mirror سے GIT_LFS_SKIP_SMUDGE=1 git clone /backups/org--repo.git /tmp/restore-test بنائیں۔ Mirror کے محفوظ lfs/objects کو test clone کی .git/lfs/objects storage میں نقل کرکے git lfs checkout چلائیں، پھر منتخب پرانے tag یا commit کی بڑی file کھول کر دیکھیں۔
Manifest میں آزمودہ commit SHA، checksum کا نتیجہ، استعمال شدہ command اور ناکامی کی remediation درج کریں۔ نئی copy کا restore کامیاب ہونے تک آخری کامیاب artifact نہ ہٹائیں۔

فیصلہ سادہ ہے: ایک version کی دوبارہ قابلِ استعمال نقل کے لیے pinned snapshot کافی ہوسکتا ہے، جبکہ audit یا سابق versions کی بحالی کے لیے Git mirror اور تمام مطلوبہ large-file objects بھی چاہییں۔ Filtered weights تبھی درست انتخاب ہیں جب manifest واضح کرے کہ کون سی files جان بوجھ کر شامل یا خارج کی گئی ہیں۔

یہ بھی پڑھیں:

Hugging Face repo کا backup بنائیں—صرف cache نقل کرنا کافی نہیں