резервное копирование git repo: архив зеркальный клон ... как насчет tar -Pzcf? - PullRequest
2 голосов
/ 19 августа 2010

Для резервного копирования git-репозитория, есть ли причина, по которой я не мог просто запустить cron, подобный этому?:

/ usr / bin / tar -Pzcf git_backup.tar.gz repo.git &&/ usr / bin / scp git_backup.tar.gz me @ other-server: / home / backup

Если что-то случится со всеми остальными копиями, я могу использовать самые последние, просто tar -xzf, в его первоначальное место,клон, пуш, пул и тд?Кажется, все должно быть хорошо, но я не уверен на 100%.Примечание: я видел другие ответы, касающиеся git clone или использования --mirror, но это кажется более простым.Это все еще варианты, если ответы показывают, что было бы лучше.

---------------- РЕДАКТИРОВАТЬ -----------------

Вот сценарий, который я в итоге создал:

#!/usr/bin/php -q
<?php

/**
 * Backup git on this box and copy it around
 *
 * cron:
 * 1 2 * * * /usr/bin/php /home/sysadmin/files/shared/git_backup.php REPO 2> /dev/null
 *
 * @package scripts
 * @author Hans Anderson <handerson@>
 */

list ( $dir, )  = explode ( '/files/', __FILE__ ); require_once ( "{$dir}/files/bootstrap.php" );
$email      = $cfg['GIT_BACKUP']['email_errors_to'];
$copy_hosts = explode(',', $cfg['GIT_BACKUP']['hosts']);

if ( !isset ($argv[1]) ) exit;

$repo = $argv[1];
$date = date ( 'Y-m-d-H' );
$user = `whoami`; $user = trim($user);

$repf = "/newdisk/git/{$repo}.git";
$bndl = "/newdisk/backup/{$repo}/git/git-{$repo}-{$date}.bndl";

chdir($repf);

$exec =  "/usr/bin/git bundle create $bndl --all";
exec ( "$exec", $error, $return );

if ( $return <> 0 ) // bad
{
    mail ( $email, "{$user} GIT Backup Failure [{$repo}]!", __FILE__ . "\nFailure to dump.\nCmd: $exec\nError: $error" );
}

foreach ( $copy_hosts as $host )
{
    $exec = "/usr/bin/scp -q {$bndl} sysadmin@{$host}:/home/sysadmin/data/backup/$repo/git";
    exec ( $exec, $error, $return );

    if ( $return <> 0 )
    {
            mail ( $email, "{$user} GIT Backup Failure [{$repo}]!", __FILE__ . "\nFailure to copy to dbs1.\nCmd: $exec\nError: " . implode ( "\n", $error ) . "\n\nReturn:" .  implode ( "\n", $return ) );
    }
}

Ответы [ 3 ]

2 голосов
/ 19 августа 2010
  • Одно из основных правил ссылочного резервного копирования: никогда не создавайте резервные копии, пока они все еще меняются.
  • Одно незначительное правило: постарайтесь получить как можно меньше файлов для резервного копирования; их перенос в другое место упрощается (несколько файлов для копирования).

Одна команда, которая может уважать эти два правила: git bundle (см. Также SO ответ )
С добавленным бонусом:

  • инкрементное резервное копирование (что означает, что процесс выполняется быстрее, чем полный архив).
  • только один файл в результате.

Уникальный полученный файл (из пакета) даже не нужно распаковывать, чтобы использовать повторно. Это Git-репо само по себе.

1 голос
/ 19 августа 2010

Единственная причина, по которой я могу думать, это то, что вы будете создавать копию всех ваших двоичных файлов (и объектных файлов ... и т. Д.). Возможно, вам нужен только репозиторий, особенно если вы собираетесь выполнять резервное копирование удаленно.

Если бы это был я, я бы сделал git-clone таким образом, чтобы резервная копия была меньше, и ее перемещение было бы быстрее.

Git спроектирован так, чтобы иметь распределенные репозитории, чтобы у вас не было проблем с SVN, когда, если центральное репо испорчено, у вас болит голова, чтобы восстановить его (если вообще возможно). Просто скопируйте мерзкие клоны повсюду :-)

0 голосов
/ 19 августа 2010

Да, это будет работать просто отлично.Единственная возможная проблема - если задание cron выполняется во время внесения изменений в репозиторий (например, посредством git push или commit).(Собственные команды git используют файлы блокировки, чтобы убедиться, что вещи всегда находятся в нормальном состоянии.)

На самом деле, более эффективный подход - использовать rsync, поэтому вам нужно только отправить новый материал черезwire - не нужно затрат и места на создание tar-архива и меньше битов для отправки по сети.

В любом случае, этот подход имеет некоторые преимущества по сравнению с использованием clone или mirror, потому что config и metaфайлы также будут скопированы (например, .git/config, .git/info/exclude, .git/hooks/* и reflog - что действительно полезно).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...