GitHub backup без лажна сигурност: mirror clone не ги зачувува сите податоци

|Автор: Уредувачки тим на QUASA|5 мин. читање| 1
GitHub backup без лажна сигурност: mirror clone не ги зачувува сите податоци

За обновлива копија на GitHub repository, направете mirror clone, одделно преземете ги Git LFS-објектите и wiki ако проектот ги користи, а потоа зачувајте архив надвор од изворниот repository. Упатството на GitHub за резервни копии ги раздвојува овие делови: Git-историјата се презема со mirror clone, LFS-објектите со дополнителна команда, а wiki како посебен Git repository.

Копијата е употреблива кога можете од зачуваниот архив да ги испратите гранките и ознаките во празен repository, да ги вратите LFS-датотеките и да ги отворите wiki-страниците. Затоа постапката опфаќа и периодично освежување и пробно враќање. Самото постоење на локалната папка не покажува дали сите потребни делови стигнале во архивот.

Што опфаќа Git-копијата

git clone --mirror ги презема Git-референците, вклучувајќи ги гранките и ознаките, и историјата до која тие водат. Тоа е основата за враќање на кодот, но GitHub чува и податоци надвор од главниот Git repository. Ако проектот користи Git LFS, Git-историјата содржи покажувачи кон големите датотеки; самите LFS-објекти треба дополнително да се преземат.

Пред копирањето утврдете дали repository има wiki и кои податоци на GitHub ви се потребни покрај кодот. Issues, pull requests, discussions, поставките и дозволите не се враќаат со испраќање на Git-референците. За тие податоци е потребна посебна постапка според бараниот опфат; пробата опишана подолу го проверува она што сте го зачувале како Git, LFS и wiki.

Направете mirror clone и освежувајте го

Во терминал со Git заменете ги OWNER и REPO со сопственикот и името на repository. За приватен проект користете сметка со пристап за читање. Следните команди извршувајте ги во иста shell-сесија, за променливата BACKUP_DIR да остане достапна и во наредните чекори.

SOURCE='https://github.com/OWNER/REPO.git'; BACKUP_DIR="$HOME/github-backups/REPO"; mkdir -p "$BACKUP_DIR"; if [ -d "$BACKUP_DIR/repo.git" ]; then git -C "$BACKUP_DIR/repo.git" fetch -p origin; else git clone --mirror "$SOURCE" "$BACKUP_DIR/repo.git"; fi

Првото извршување создава огледална копија, а следните ги преземаат промените. Документацијата на GitHub за огледални копии ги наведува git fetch -p origin за освежување и git push --mirror за испраќање во друг repository. Опцијата -p ги отстранува од тековното огледало референците што се избришани од изворот. Затоа зачувајте одделни архивирани снимки ако треба да можете да се вратите и на постара состојба.

Ако проектот користи Git LFS, инсталирајте го Git LFS и по секое преземање на Git-промените извршете git -C "$BACKUP_DIR/repo.git" lfs fetch --all. Почекајте командата да заврши успешно пред архивирање: Git-покажувач без соодветниот LFS-објект не ја враќа содржината на датотеката. Ако преземањето е одбиено или прекинато, таа снимка не е целосна според опфатот што сте го избрале.

Зачувајте го wiki од неговата адреса

Wiki на GitHub има сопствен Git repository, со адреса што завршува на .wiki.git. Упатството за GitHub wiki покажува дека клонирањето е достапно откако е создадена почетна страница. Ако проектот има wiki со содржина, зачувајте го покрај главниот mirror.

WIKI='https://github.com/OWNER/REPO.wiki.git'; if [ -d "$BACKUP_DIR/wiki.git" ]; then git -C "$BACKUP_DIR/wiki.git" fetch -p origin; else git clone --mirror "$WIKI" "$BACKUP_DIR/wiki.git"; fi

И за wiki проверете дали командата завршила успешно. Грешка поради адреса или пристап не значи дека проектот нема wiki. Неговата копија се освежува одделно од главниот repository, па вклучете ги двата директориума во истата архивирана снимка кога wiki е дел од проектот.

Архивирајте по успешно преземање

Откако ќе завршат сите применливи чекори, архивирајте ја целата папка. Следнава команда создава снимка покрај работната папка, па архивот нема да се вклучи самиот себеси: ARCHIVE="$HOME/github-backups/REPO-$(date +%Y%m%d-%H%M%S).tar.gz"; tar -czf "$ARCHIVE" -C "$BACKUP_DIR" . Префрлете го добиениот архив на одделно место за чување и проверете дали може да се прочита таму.

Одредете го ритамот на освежување според тоа колку нови промени можете да си дозволите да изгубите. Истите команди може да ги извршува периодична задача, но архивирањето треба да следи само по успешни преземања на Git, LFS и wiki, кога тие се применливи. Чувањето повеќе снимки е важно и по бришење гранка или ознака: следното fetch -p ќе ја усогласи тековната копија со изворот.

Вратете ја снимката во празен repository за проба

За пробата употребете го зачуваниот архив, по можност копијата од одделното место за чување, наместо работната папка што сè уште се освежува. Распакувајте го во нов директориум, на пример со TEST_DIR="$HOME/github-restore-test"; mkdir -p "$TEST_DIR"; tar -xzf "/ПАТЕКА/ДО/АРХИВОТ.tar.gz" -C "$TEST_DIR". Заменете ја примерната патека со вистинската локација на архивот. Така пробата ги користи податоците што би ви биле достапни при враќање.

Создајте празен GitHub repository без почетна датотека, па испратете ги референците со git -C "$TEST_DIR/repo.git" push --mirror https://github.com/OWNER/RESTORE-TEST.git. Проверете ја одредишната адреса пред извршување: push --mirror може да ги пребрише или избрише референците што веќе постојат таму. Клонирајте го пробниот repository на нова локација и проверете дали очекуваните гранки, ознаки и постари измени се достапни.

Ако снимката содржи LFS-објекти, испратете ги со git -C "$TEST_DIR/repo.git" lfs push --all https://github.com/OWNER/RESTORE-TEST.git. Во свежиот клон, со инсталиран Git LFS, отворете датотека што користи LFS и проверете дали се добива нејзината содржина, а не само покажувач. Доколку во архивот има wiki.git, овозможете wiki во пробниот repository, создајте почетна страница ако е потребно за неговата Git-адреса и испратете ја копијата со git -C "$TEST_DIR/wiki.git" push --mirror https://github.com/OWNER/RESTORE-TEST.wiki.git. Отворете ги wiki-страниците во пробниот repository; одбиено испраќање или недостасувачка содржина значи дека постапката за враќање треба да се поправи.

Прочитајте и:

Сподели:

Претплатете се на нашиот билтен

Добивајте ги најновите вести за Web3, AI и крипто директно во вашето сандаче.

0