Uruchomiłem na Szewie #2 serwer WWW, dostępny pod adresem pinkaccordions.homelinux.org (darmowa domena z serwisu dyndys.com -- w moim przypadku konieczność, bo mam tzw. zmienne IP). Jak już jest serwer, to trzeba robić -- w sposób systematyczny, a nie ad hoc -- kopie zapasowe na wypadek gdyby, np. karta padła (co podobno nie jest takie rzadkie...). Po konsultacji z tym co w tym temacie proponują inni postanowiłem robić to za pomocą rsync
a, uruchamianego z zewnętrznego komputera.
W tym celu trzeba zainstalować rsync na obu komputerach źródłowym i tym, na którym będzie tworzona kopia:
apt-get install rsync
Teraz należy skonfigurować rsync
po stronie źródła (czyli tego komputera, z którego mają być kopiowane dane) modyfikując /etc/rsyncd.conf
. Zawartość pliku /etc/rsyncd.conf
w moim przypadku wygląda następująco:
## http://encodable.com/tech/blog/2005/10/13/Secure_Remote_Backups_via_rsync
uid = 0
gid = 0
hosts allow = *****
transfer logging = no
read only = yes
[wholefs]
path = /
comment whole root fs
[pinkaccordions]
path = /var/www_pinkaccordions/
comment pinkaccordions www
Można sprawdzić czy działa (neptune
jest zadeklarowany w /etc/hosts
):
rsync neptune::wholefs/
Tworzenie kopii realizuje skrypt rsync_neptune.sh
uruchamiany po stronie przeznaczenia:
#!/bin/bash
SOURCE=neptune::wholefs/
EXCLUDE=/root/.rsync/backup_exclude.lst
DESTDIR=/backup/neptune/rootfs
echo "=== Syncing ${SOURCE} at `date` ==="
rsync -av --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}
Plik $EXCLUDE
zawiera te katalogi, które nie powinny -- z oczywistych względów -- być kopiowane (zawartości katalogów /proc
, /sys
oraz /tmp
):
## Exclude
- /proc/*
- /sys/*
- /tmp/*
Skrypt rsync_neptune.sh
jest zaś uruchamiany poprzez cron
a:
0 4 * * 7 /root/bin/rsync_neptune.sh >> /root/logs/RSync/RSync.log 2>&1
Idea jest taka: kopia całego rootfs
z karty SDHC ma być wykonywana na dysk USB raz w tygodniu (z innego komputera, konkretnie Szewy #1). W razie potrzeby (awarii karty SDHC) kopia ta może być szybko przeniesiona na inną kartę SDHC... Można też kopiować bezpośrednio na kartę SDHC wsadzoną na zicher w czytnik kart, ale nie widzę sensu podłączania czytnika wyłącznie i tylko po to, żeby w razie awarii, mieć kopię karty od razu a nie po 3 minutach.
Zatem:
#!/bin/bash
EXCLUDE=/root/.rsync/backup_exclude.lst
SOURCE=/public/sheeva/backup/neptune/rootfs/
DESTDIR=/media/sd_backup
# http://www.cyberciti.biz/tips/shell-root-user-check-script.html
# Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
echo "This script must be run as root" 1>&2 ; exit 1
fi
## sprawdz czy karta jest w czytniku i jest zamontowana
if [ -d "$DESTDIR" ] ; then
echo "** OK: $DESTDIR!"
else
echo "** ERROR: $DESTDIR not mounted!"; exit 1;
fi
rsync -av --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}
No i tu porażka:
rsync: readlink_stat("/media/sd_backup/etc/shadow") failed: Input/output error (5)
rsync: readlink_stat("/media/sd_backup/etc/resolv.conf") failed: Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/etc/resolv.conf": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/etc/shadow": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/etc/network/run/ifstate": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/var/lib/urandom/random-seed": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/var/log/lastlog": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/var/run/dhclient.eth0.pid": Input/output error (5)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1058) [sender=3.0.5]
Trefne pliki (w liczbie sześciu, jak widać) mają długość 0 bajtów, a próba np. ls -li /media/sd_backup/etc/shadow
powoduje komunikat I/O error
. Usunąć tego też się nie da (rm -f
nie daje rady)...
Wobec powyższego, sformatowałem partycję i wykonałem kopię za pomocą następującego polecenia wykorzystując tar
a:
tar cf - . | (cd /media/sd_backup/; tar xvpf - ) 2> ../../tar.log
Po wsadzeniu kopii zamiast oryginału do Szewy, system wydaje się działać. Czemu rsync
zawiódł nie wiem (na razie)...
Dopisane 27 maja 2010 (po południu): Log tara
(2> ../../tar.log
) zawierał masę wpisów: implausibly old time stamp 1960-04-13 04:17:36. Data jest absurdalna. Żeby było śmieszniej w systemie była inna (w przód 2028 rok -- licznik się przekręcił tar
owi?). Pliki z błędnym czasem modyfikacji były głównie w katalogach /dev/
/var/
oraz /etc/
; wygląda jakby w czasie inicjalizacji, przed uruchomieniem ntpdate
,,fabryczny'' zegar Szewy wskazywał coś dziwacznego.
Czasy poprawiłem touch
em. Zrobiłem rsync
na dysk, a potem z dysku na kartę zapasową. Tym razem błędów nie było...
Dopisane 10 Kwietnia 2011: Poprawiłem skrypt rsync_neptune.sh
na możliwą okoliczność wykonania kopii z uszkodzonych danych. W nowej wersji tworzone są trzy kopie z dwutygodniowym horyzontem czasowym:
#!/bin/bash
# rsync_neptune.sh (wersja poprawiona)
SOURCE=neptune::wholefs/
EXCLUDE=/root/.rsync/backup_exclude.lst
DESTDIR=/public/sheeva/backup/neptune/rootfs
COPYDIR=/public/sheeva/backup/neptune
### Zachowaj stara kopie pod inna nazwa:
cp -f ${COPYDIR}/1week.tar.gz ${COPYDIR}/2week.tar.gz
### Zachowaj stare dane (sprzed tygodnia):
tar -zcPf ${COPYDIR}/1week.tar.gz ${DESTDIR}
echo "=== Syncing ${SOURCE} at `date` ==="
rsync -av --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}
Powinienem w ciągu dwóch tygodni się połapać, że coś jest nie tak, np. z kartą.
Brak komentarzy:
Prześlij komentarz