GIT sebagai alat cadangan

101

Di server, instal git

cd /
git init
git add .
git commit -a -m "Yes, this is server"

Kemudian /.git/arahkan ke drive jaringan (SAN, NFS, Samba apa pun) atau disk yang berbeda. Gunakan pekerjaan cron setiap jam / hari dll untuk memperbarui perubahan. Direktori .git akan berisi salinan versi semua file server (tidak termasuk yang tidak berguna / rumit seperti / proc, / dev, dll.)

Untuk server pengembangan yang tidak penting di mana saya tidak ingin kerumitan / biaya pengaturannya pada sistem cadangan yang tepat, dan di mana cadangan hanya untuk kenyamanan (IE kita tidak perlu membuat cadangan server ini tetapi itu akan menghemat kadang-kadang jika ada yang salah), dapatkah ini menjadi solusi cadangan yang valid atau akankah itu jatuh ke tumpukan besar?

Noda
sumber
3
tidak memunculkan masalah menggunakan ide serupa ??
B14D3
@ B14D3 Saya pikir sparkleshare lebih merupakan semacam jenis dropbox, tapi saya akan memeriksanya
Smudge
2
Anda benar, tetapi menggunakan git untuk membuat semacam buckup thing (menyalin ke beberapa pc dan mengontrol versi file);)
B14D3
Masalah besar dengan hal ini adalah bahwa tidak ada kontrol pusat - Anda harus memiliki akses (ssh) langsung ke mesin untuk melakukan pra-bentuk segala bentuk perawatan atau validasi cadangan. Saya selalu menemukan menginstal aplikasi pada kotak yang akan didukung kemudian mengelola mereka dari lokasi pusat adalah kemenangan yang jauh lebih besar.
hafichuk
@ hafichuk Dengan alat seperti Wayang / Koki, itu bukan masalah besar, tapi saya mengerti maksud Anda.
Smudge

Jawaban:

88

Anda bukan orang yang bodoh. Menggunakan gitsebagai mekanisme cadangan bisa menarik, dan terlepas dari apa yang orang lain katakan, gitberfungsi dengan baik dengan file biner. Baca halaman ini dari Buku Git untuk informasi lebih lanjut tentang topik ini. Pada dasarnya, karena gittidak menggunakan mekanisme penyimpanan delta, itu tidak benar-benar peduli seperti apa file Anda terlihat (tetapi utilitas git diffcukup rendah untuk file biner dengan konfigurasi stok).

Masalah terbesar dengan menggunakan gituntuk cadangan adalah itu tidak melindungi sebagian besar metadata sistem file. Secara khusus, gittidak merekam:

  • grup file
  • pemilik file
  • izin file (selain "apakah ini dapat dieksekusi")
  • atribut yang diperluas

Anda dapat menyelesaikan ini dengan menulis alat untuk mencatat informasi ini secara eksplisit ke dalam repositori Anda, tetapi mungkin sulit untuk melakukannya dengan benar.

Pencarian Google untuk metadata cadangan git menghasilkan sejumlah hasil yang tampaknya layak dibaca (termasuk beberapa alat yang sudah berupaya untuk mengkompensasi masalah yang saya ajukan di sini).

dllkeeper dikembangkan untuk mendukung /etcdan memecahkan banyak masalah ini.

larsks
sumber
16
+1 untuk menyebutkan ACL / izin
Larry Silverman
23
Git juga tidak menyimpan direktori kosong.
Flimm
dan itu juga menyebalkan untuk melacak / memindahkan nama file, melalui histori.
cregox
1
Karena git tidak menangani file biner dengan sangat baik, Anda mungkin juga ingin melihat lampiran git , yang membantu melakukannya dengan lebih baik. Itu memang mengubah gagasan tentang apa itu git.
Wouter Verhelst
1
pendapat saya adalah bahwa Anda dapat menggunakan git untuk membuat cadangan data tetapi tidak seluruh server
EKanadily
21

Saya belum menggunakannya, tetapi Anda mungkin melihat bup yang merupakan alat cadangan berdasarkan git.

rebus
sumber
Belum pernah melihat bup sebelumnya, terlihat menarik
Smudge
1
Saya sudah mulai menggunakan bup baru-baru ini, hanya beberapa hari sebelum hard drive saya jatuh;) Restore baik-baik saja, sangat disarankan!
André Paramés
1
@ AndréParamés jadi apa yang Anda katakan adalah hanya setelah Anda menginstal bup hard drive Anda rusak ... mmmmhh ... :) hanya bercanda
hofnarwillie
12

Ini bisa menjadi solusi cadangan yang valid, dan lain-lain penjaga berdasarkan ide ini. Tetapi mengawasi .gitizin direktori jika tidak mendorong /etc/shadowdapat dibaca di .gitdirektori.

Batu
sumber
11

Sementara secara teknis Anda bisa melakukan ini saya akan menempatkan dua peringatan terhadapnya:

1, Anda menggunakan sistem kontrol versi sumber untuk data biner. Karena itu Anda menggunakannya untuk sesuatu yang tidak dirancang untuk itu.

2, saya khawatir tentang proses pengembangan Anda jika Anda tidak memiliki proses (dokumentasi atau otomatis) untuk membangun mesin baru. Bagaimana jika Anda tertabrak membeli bus, siapa yang tahu apa yang harus dilakukan dan apa yang penting?

Pemulihan bencana penting, namun lebih baik untuk mengotomatiskan (skrip) pengaturan kotak pengembangan baru daripada hanya mencadangkan semuanya. Tentu gunakan git untuk skrip / dokumentasi Anda tetapi tidak untuk setiap file di komputer.

Phil Hannent
sumber
4
Kotak pengembangan semua berasal dari file KickStart, dan sebenarnya kotak rata-rata berlangsung sekitar 2 atau 3 bulan sebelum dibangun kembali. Tetapi orang-orang mengubah konfigurasi dan melakukan hal-hal, kami membangun kembali kotak-kotak itu dan orang-orang berkata "hei, saya tahu saya tidak meletakkannya di kontrol sumber tetapi saya punya beberapa omong kosong di kotak itu" dan saya menertawakan mereka karena bodoh. Di sekitar, masa-masa yang menyenangkan. Data biner akan menyebalkan, itu sesuatu yang benar-benar saya abaikan saat mandi.
Smudge
Saya memuji sikap Anda terhadap mereka yang gagal mengikuti kepala sekolah dasar. Secara pribadi saya memiliki situasi yang serupa dengan Anda, namun saya memiliki repositori git yang menautkan semua file konfigurasi yang mungkin penting daripada menangkap semua. Ditambah dokumen txt dengan langkah-langkah pengaturan.
Phil Hannent
1
Saya pikir git bekerja cukup baik untuk file biner, vide bagian terbesar Google Android dari repo adalah repositori git dari file executable prebuilt.
user377178
6

Saya menggunakan git sebagai cadangan untuk sistem Windows saya, dan ini sangat berguna. Di bagian bawah posting, saya menunjukkan skrip yang saya gunakan untuk mengkonfigurasi pada sistem Windows. Menggunakan git sebagai cadangan untuk sistem apa pun memberikan 2 keuntungan besar:

  1. Tidak seperti solusi komersial yang sering menggunakan format milik mereka sendiri, cadangan Anda dalam format open source yang didukung secara luas dan didokumentasikan dengan sangat baik. Ini memberi Anda kendali penuh atas data Anda. Sangat mudah untuk melihat file mana yang berubah dan kapan. Jika Anda ingin memotong riwayat Anda, Anda dapat melakukannya juga. Ingin menghapus sesuatu dari riwayat Anda? Tidak masalah. Mendapatkan versi file Anda kembali sesederhana perintah git.
  2. Sebanyak atau sesedikit cermin yang Anda inginkan, dan semua dapat memiliki waktu pencadangan khusus. Anda akan mendapatkan mirror lokal Anda, yang tidak terbebani oleh lalu lintas Internet yang lambat, dan dengan demikian memberi Anda (1) kemampuan untuk melakukan backup lebih sering sepanjang hari dan (2) waktu pemulihan yang cepat. (Pencadangan yang sering merupakan nilai tambah yang besar, karena saya menemukan waktu paling banyak saya kehilangan dokumen adalah karena kesalahan pengguna. Misalnya, anak Anda secara tidak sengaja menimpa dokumen yang sedang dikerjakannya selama 5 jam terakhir.) Tetapi Anda akan mendapatkan remote mirror, yang memberikan keuntungan perlindungan data jika terjadi bencana atau pencurian lokal. Dan misalkan Anda ingin membuat mirror jarak jauh Anda pada waktu yang disesuaikan untuk menghemat bandwidth internet Anda? Tidak masalah.

Intinya: Cadangan git memberi Anda kekuatan luar biasa dalam mengendalikan bagaimana cadangan Anda terjadi.

Saya mengkonfigurasi ini pada sistem Windows saya. Langkah pertama adalah membuat repo git lokal tempat Anda akan mengkomit semua data lokal Anda. Saya sarankan menggunakan hard drive lokal kedua, tetapi menggunakan harddrive yang sama akan bekerja untuk (tetapi diharapkan Anda akan mendorong ini di suatu tempat yang jauh, atau jika Anda gagal jika harddrive mati.)

Pertama-tama Anda harus menginstal cygwin (dengan rsync), dan juga menginstal git untuk Windows: http://git-scm.com/download/win

Selanjutnya, buat repo git lokal Anda (hanya berjalan sekali):

init-repo.bat:

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

Selanjutnya, kami memiliki pembungkus skrip cadangan kami, yang akan dipanggil secara teratur oleh Penjadwal Windows:

gbackup.vbs:

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

Selanjutnya, kami memiliki skrip cadangan sendiri yang dipanggil oleh bungkus:

gbackup.bat:

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

Kami memiliki file exclude-from.txt, tempat kami meletakkan semua file untuk diabaikan:

kecualikan-dari.txt:

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

Anda harus pergi ke repo jarak jauh dan melakukan 'git init --bare' pada mereka. Anda dapat menguji skrip dengan menjalankan skrip cadangan. Dengan asumsi semuanya berfungsi, buka Penjadwal Windows dan arahkan cadangan per jam ke file vbs. Setelah itu, Anda akan memiliki riwayat git komputer Anda setiap jam. Ini sangat nyaman - setiap bagian teks terhapus secara tidak sengaja dan ketinggalan? Cukup periksa repositori git Anda.

user64141
sumber
Hanya ingin tahu - apakah ini akan berfungsi juga untuk drive jaringan yang lambat atau tidak standar, seperti yang ditiru oleh NetDrive atau Expandrive? Saya menemukan sebagian besar perangkat lunak cadangan gagal dengan drive jaringan ini. Hal-hal yang lambat dan cenderung menjadi time-out, jika saya ingin daftar semua file dalam cadangan dan ekstrak file individual. Apakah git dapat menyelesaikan masalah ini?
JustAMartin
@JustAMartin Saya belum pernah mengujinya di drive jaringan, jadi saya tidak bisa mengatakannya. Setelah Anda mendapatkan file dalam repo git, git sangat efisien.
user64141
4

Yah itu bukan ide yang buruk, tapi saya pikir ada 2 bendera merah yang harus dinaikkan:

  • Jika harddisk gagal, Anda akan kehilangan segalanya jika Anda tidak mendorong komit ke server / drive lain. (Acara jika Anda memiliki rencana untuk itu, saya lebih suka menyebutkan.)

... tapi tetap saja, ini bisa menjadi cadangan yang bagus untuk hal-hal yang berkaitan dengan korupsi. Atau seperti yang Anda katakan, jika .git / folder berada di tempat lain.

  • Ukuran cadangan ini akan selalu bertambah. Tidak ada pemangkasan atau rotasi atau apa pun secara default.

... Jadi, Anda mungkin perlu memberi tahu cronjob Anda untuk menambahkan tag, dan kemudian pastikan komit yang tidak ditandai akan dibersihkan.

FMaz008
sumber
Kita mungkin akan me-mount direktori .git pada server jauh, walaupun clasic rm -Rf /akan menyebabkan kita mengalami beberapa masalah. Sistem cadangan kami saat ini menyimpan barang selama 2 tahun atau 50 versi (mana yang terakhir) sehingga cadangan kami terus meningkat. Tapi saya suka ide menambahkan tag, kita bisa memiliki tag "harian", "mingguan" dll.
Smudge
+1 untuk kebutuhan ruang yang terus tumbuh
hafichuk
@sam git terus berkembang. Anda tidak dapat memangkas sejarah yang lebih tua dari N tahun. Saya kira sistem Anda saat ini.
rds
1
Mengenai peningkatan ukuran, silakan lakukan 'git gc' secara teratur atau sebelum Anda mendorong ke server lain (sentral). Tanpa ini, repo git dapat tumbuh (jauh) lebih besar dari yang seharusnya. Saya pernah punya repo git 346 MB yang bisa menyusut ke 16 MB.
Hendy Irawan
3

Saya belum mencobanya dengan sistem lengkap tetapi saya menggunakannya untuk backup MySQL saya (dengan opsi --skip-extended-insert) dan itu benar-benar bekerja dengan baik untuk saya.

Anda akan mengalami masalah dengan file data biner (seluruh isinya bisa dan akan berubah) dan Anda mungkin memiliki masalah dengan .gitfolder yang semakin besar. Saya akan merekomendasikan mengatur .gitignorefile dan hanya membuat cadangan file teks yang Anda benar-benar tahu Anda butuhkan.

Scott Keck-Warren
sumber
Saya menggunakannya untuk backup MySQL juga, dengan --extended-insert = false. Pastikan untuk "git gc" secara teratur atau tepat setelah komit.
Hendy Irawan
3

Saya pernah mengembangkan solusi cadangan berdasarkan subversi. Walaupun ini bekerja cukup baik (dan git harus bekerja lebih baik), saya pikir ada solusi yang lebih baik di sini.

Saya menganggap rsnapshot menjadi salah satu lebih baik - jika tidak yang lebih baik. Dengan penggunaan hard link yang baik, saya memiliki server file 300 GB (dengan setengah juta file) dengan cadangan harian, mingguan, dan bulanan akan kembali sejauh satu tahun. Total ruang disk yang digunakan hanya satu salinan lengkap + bagian inkremental dari setiap cadangan, tetapi berkat hardlink saya memiliki struktur direktori "live" yang lengkap di setiap cadangan. Dengan kata lain, file dapat diakses secara langsung tidak hanya di bawah daily.0 (cadangan terbaru), tetapi bahkan dalam daily.1 (yestarday) atau mingguan.2 (dua minggu lalu), dan sebagainya.

Membagikan ulang folder cadangan dengan Samba, pengguna saya dapat menarik file dari cadangan hanya dengan mengarahkan PC mereka ke server cadangan.

Pilihan lain yang sangat bagus adalah rdiff-backup , tetapi karena saya ingin memiliki file yang selalu dapat diakses hanya dengan menuju Explorer ke \\ servername, rsnapshot adalah solusi yang lebih baik bagi saya.

shodanshok
sumber
Rdiff-backup rilis terakhir adalah dari tahun 2009. Apakah ini dirancang dengan sangat baik dan tidak memerlukan pembaruan sama sekali atau hanya proyek yang ditinggalkan?
Mateusz Konieczny
Saya tidak tahu apakah itu dipertahankan, tetapi pada dasarnya "selesai".
shodanshok
Dari melihat savannah.nongnu.org/bugs/... tampaknya ada beberapa kegiatan hingga 2015 tetapi banyak laporan bug diabaikan. Saya pikir saya akan mengklasifikasikannya sebagai yang ditinggalkan.
Mateusz Konieczny
2

Saya punya ide yang sama untuk mencadangkan dengan git, pada dasarnya karena memungkinkan pencadangan berversi. Kemudian saya melihat rdiff-backup , yang menyediakan fungsionalitas itu (dan banyak lagi). Ini memiliki antarmuka pengguna yang sangat bagus (lihat opsi CLI). Saya cukup senang dengan itu. Itu --remove-older-than 2Wsangat keren. Ini memungkinkan Anda untuk menghapus versi yang lebih lama dari 2 minggu. rdiff-backuphanya menyimpan beberapa file.

Daniel
sumber
2

Saya sangat baru di git, tetapi bukankah cabang lokal secara default, dan harus didorong secara eksplisit ke repositori jarak jauh? Ini adalah kejutan yang tidak menyenangkan dan tidak terduga. Lagi pula, bukankah saya ingin semua repo lokal saya 'dicadangkan' ke server? Membaca buku git :

Cabang lokal Anda tidak secara otomatis disinkronkan dengan remote yang Anda tulis - Anda harus mendorong cabang yang ingin Anda bagikan secara eksplisit. Dengan begitu, Anda bisa menggunakan cabang pribadi untuk pekerjaan yang tidak ingin Anda bagikan, dan mendorong hanya cabang topik yang ingin Anda kolaborasi.

Bagi saya ini berarti bahwa cabang-cabang lokal tersebut, seperti file non-git lainnya di mesin lokal saya, beresiko hilang kecuali didukung secara teratur dengan beberapa cara non-git. Saya melakukan ini, tetapi itu mematahkan asumsi saya tentang git 'mendukung semuanya' di repo saya. Saya ingin klarifikasi!

Matthew Cornell
sumber
1
Hampir semua tentang git dengan pengecualian remote adalah lokal. Itu dengan desain. Anda dapat mendorong hal-hal ke remote, dan harus, terutama jika digunakan untuk cadangan seperti dalam skenario ini. Untuk cabang, sekali lagi, ya, Anda perlu mendorongnya secara eksplisit jika Anda ingin mereka ditambahkan ke remote. Untuk pengembangan, ini bagus karena sering kali Anda ingin menguji sesuatu, tetapi cabang tes tidak perlu dilestarikan tanpa batas waktu. Setelah Anda memiliki apa yang Anda butuhkan dari itu, Anda kemungkinan akan menggabungkannya ke cabang dev dan del cabang uji.
LocalPCGuy
1

Saya menemukan ini menjadi metodologi yang baik untuk kotak dev saya. Itu mengubah mereka dari menjadi sesuatu yang perlu didukung hanya ke titik akhir penyebaran.

Semua manifes konfigurasi dan instalasi paket disimpan di Puppet, memungkinkan pemindahan yang mudah dan pembaruan konfigurasi. Direktori Wayang didukung dengan git. Kickstart digunakan untuk melakukan penyebaran awal.

Saya juga menyimpan repositori YUM khusus untuk paket apa pun yang sedang dikembangkan saat itu. Ini memiliki manfaat tambahan bahwa paket apa pun yang sedang kami kerjakan tidak hanya dibiarkan sebagai binari tanpa pengawasan di sistem lokal - jika itu terjadi dan file-file akan nuked oh well. Seseorang tidak mengikuti prosedur yang benar.

Tim Brigham
sumber
1

Anda mungkin ingin memeriksa bup di github yang dirancang untuk melayani tujuan menggunakan git untuk cadangan.

mcantsin
sumber
jawaban sebelumnya sudah menunjuk ke alat yang sama (bup). serverfault.com/a/341213/303467 . Adakah highlight di dalamnya?
Javier
1

Ini adalah pendekatan yang digunakan, masuk akal.

Keepconf gunakan rsync dan git untuk pekerjaan ini, itu adalah pembungkus alat ini untuk menjaga hal itu mudah.

Anda hanya memerlukan server pusat dengan kunci ssh yang dikonfigurasi untuk akses ke server cadangan dan beberapa baris dalam file konfigurasi. Sebagai contoh, ini adalah file saya sendiri untuk menyimpan semua / etc / dan paket debian diinstal:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

Dengan itu, saya memiliki cadangan rsync dan git commit.

Rfraile
sumber
0

Pendapat pribadi saya adalah bahwa ini pada dasarnya semua mundur. Anda mendorong file ke dalam solusi cadangan, bukan menariknya keluar.

Jauh lebih baik untuk memusatkan konfigurasi server di tempat pertama, dan kemudian menariknya ke bawah, menggunakan sesuatu seperti boneka.

Yang mengatakan, itu mungkin berhasil, saya hanya tidak berpikir itu akan baik.

Coba cari di backuppc - ini cukup mudah untuk diatur dan terus terang brilian.

Sirex
sumber
0

Ini akan bekerja agak, tetapi dua peringatan

  1. Penambahan file tidak akan diambil secara otomatis saat Anda melakukan commit. Gunakan status --porcelean om git untuk menemukan hal baru untuk ditambahkan sebelum melakukan komit.

  2. Mengapa kerumitan pemasangan jarak jauh untuk .ssh? Itu mungkin rapuh Bd Anda tidak akan tahu bahwa itu gagal. Gunakan repositori kosong untuk ujung jauh dengan login kunci ssh normal. Selama repositori kosong dan Anda hanya mendorong dari satu sumber dijamin untuk bekerja tanpa penggabungan.

Andrew
sumber