rsync: send_files failed to open ongelma

[noobuntu]

Hei,

Alkuun hieman alustusta.
Olen koittanut kehitellä Ubuntu koneilleni jonkinlaista varmuuskopiointi menetelmää, jolla saan kannettavani, pöytäkoneeni tai palvelimeni mahdollisen virhetilanteen jälkeen tilaan jossa kaikki oli vielä kunnossa.
Ainakin pöytäkoneella tuo tulee tarpeeseen, sillä aikaajoin tulee testailtua kaikenlaisia juttuja koneella, joiden seurauksena on tullut uudelleen asennuskuviot tutuiksi

Tietoa etsiessäni törmäsin tähän linkkiin: https://ubuntuforums.org/showthread.php?t=1198700
Sainkin linkin avulla tehtyä kannettavalleni toimivan varmuuskopiointi menetelmän, joka ainakin alkutestien perusteella näyttäisi toimivan kuten tarkoitus olikin.

Koitin siirtää idean myös juuri asennetulle Ubuntu 16.04.3 LTS palvelimelle mutta aivan ongelmitta homma ei nyt näytä lähtevän liikkeelle.
Siltä varalta, että asialla on jotakin merkitystä, niin palvelimella on käytössä LVM.

Tein oman /home hakemiston alla olevaan /bin hakemistoon backup.sh tiedoston, jossa varsinainen rsycn komento on.
/bin hakemisto on lisäty PATH:in backup.sh tiedostolle on annettu suoritus oikeudet.
Näin ollen backup.sh tiedosto voidaan missä hakemistossa tahansa.

Rsync prosessi näyttää menevän loppuun mutta lokitiedostossa on monta riviä jotka liittyvät tähän: "/var/lib/lxcfs/cgroup/blkio/blkio.reset_stats": Permission denied (13)
Kummastuttaa tuo Permission denied, sillä suoritan kuitenkin alla näkyvän komennon kuitenkin sudo oikeuksin.

sudo rsync --delete-after -avz --exclude-from=/ei_mukaan_varmuuskopiointiin / /usr/backup/ --log-file=/tmp/rsync-Full-backup-`date +"%Y-%m-%d-%H-%M"`.log

Tässä ei_mukaan_varmuuskopiointiin tiedoston sisältö:
dev
run
tmp
proc
mnt
lost+found
sys
usr/backup

Eli, voiko nuo rivit jättää huomiotta vai pitäisikö hakemisto /var/lib/lxcfs lisätä myös tiedostoon: ei_mukaan_varmuuskopiointiin?
Jos rivejä ei voi jättää huomiotta, niin kuinka tuo permission denied ongelma ratkaistaan?

Tällä hetkellä lxc tai lxd ei ole käytössä, eli en ole luonut noita "säiliöitä" mutta jossakin vaiheessa voisi olla mielenkiintoista tutustua niihinkin, joten en haluaisi poistaa lxcfs:ää, jos nyt edes on mahdollista, palvelimelta.

[retu]

En nyt tiedä tuosta nimenomaisesta pulmasta, mutta pisti silmään että kopioit /var/backup hakemistoon. Siellä on tavallisesti paketinhallinnan tiedostoistaan tekemiä kopioita. Laittaisin omatekemät kopiot omaan hakemistoonsa. Lisäksi, ellet ole liittänyt ko. hakemistoon jotain toista levyä, ei ole kovin hyvä ajatus tehdä varmuuskopioita sinne. Levyn poksahtaessa varmuuskopio häviää samalla kuin muutkin tiedostot.

Kun kerran käytät rsync komentoa, mikset kopioisi samantien toiselle koneelle? Se onnistuu ssh yhteyden yli helposti ja tiedostot olisivat paljon paremmassa turvassa.

En myöskään kopioisi koko juurihakemistoa, vaan /home (ja ehkä /etc) hakemiston. Palvelinkoneelta ohjelmien data-hakemistot, kuten /var/www, riippuen siitä mitä palvelimelle on asennettu. Ohjelmathan saa asennettua uudelleen. Tietokannan, kuten mysql, kopiointi kannattaa tehdä siihen tarkoitetulla ohjelmalla.

LVM:ää en käytä, mutta löysin tämmöisen ohjeen: http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html
(ehkä siitä on apua, jos välttämättä haluat kopioida koko osion)

[nm]

Rsync prosessi näyttää menevän loppuun mutta lokitiedostossa on monta riviä jotka liittyvät tähän: "/var/lib/lxcfs/cgroup/blkio/blkio.reset_stats": Permission denied (13)
Kummastuttaa tuo Permission denied, sillä suoritan kuitenkin alla näkyvän komennon kuitenkin sudo oikeuksin.

/var/lib/lxcfs on LXCFS-tiedostojärjestelmän FUSE-liitos. Oikeusongelma johtunee jonkin asteisesta bugista toteutuksessa:

https://github.com/bit-team/backintime/issues/782
https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1656309
https://superuser.com/questions/1142269/some-file-permissions-have-under-lxc-is-this-a-feature-or-a-sign

/var/lib/lxcfs:ää ei joka tapauksessa kannata varmuuskopioida, koska se sisältää vain /proc-tiedostojärjestelmää muistuttavan näkymän kernelin tietorakenteisiin ja suodatetun näkymän containereiden tiedostojärjestelmiin. Siellä ei ole mitään palautettavaa.

[noobuntu]

Kiitos retu ja nm vastauksistanne.

En nyt tiedä tuosta nimenomaisesta pulmasta, mutta pisti silmään että kopioit /var/backup hakemistoon.

Hetkinen... mistäs sellaiseen päätelmmän päädyit?
Tuossa rsycn komennossahan on tallennuskohteena: /usr/backup/

Laittaisin omatekemät kopiot omaan hakemistoonsa. Lisäksi, ellet ole liittänyt ko. hakemistoon jotain toista levyä, ei ole kovin hyvä ajatus tehdä varmuuskopioita sinne. Levyn poksahtaessa varmuuskopio häviää samalla kuin muutkin tiedostot.

Kun kerran käytät rsync komentoa, mikset kopioisi samantien toiselle koneelle? Se onnistuu ssh yhteyden yli helposti ja tiedostot olisivat paljon paremmassa turvassa.

Olet oikeassa. Selitin suunnitelmani hieman puutteellisesti ja oikeastaan siksi, että nuo muut varmuuskopioinnin stepit eivät liittyneet enää tuohon varsinaiseen ongelmaan.
Tarkoitus siis on ensin tehdä varmuuskopiointi tuonne /usr/backup hakemistoon ja sen jälkeen oli tarkoitus pakata backup hakemisto ja siirtää se jonnekin turvaan.
Aivan kuten tuossa esimerkki linkissäkin oli tehty.

En myöskään kopioisi koko juurihakemistoa, vaan /home (ja ehkä /etc) hakemiston. Palvelinkoneelta ohjelmien data-hakemistot, kuten /var/www, riippuen siitä mitä palvelimelle on asennettu. Ohjelmathan saa asennettua uudelleen. Tietokannan, kuten mysql, kopiointi kannattaa tehdä siihen tarkoitetulla ohjelmalla.

LVM:ää en käytä, mutta löysin tämmöisen ohjeen: http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html
(ehkä siitä on apua, jos välttämättä haluat kopioida koko osion)

Kiitos snapshot linkistä ja noihin hakemistoihin liittyvästä kommenteista.

/var/lib/lxcfs on LXCFS-tiedostojärjestelmän FUSE-liitos. Oikeusongelma johtunee jonkin asteisesta bugista toteutuksessa:

https://github.com/bit-team/backintime/issues/782

Tuohon linkkiin törmäsin itsekin kun haeskelin ratkaisua pulmaani.
Mutta linkissä ratkaisuksi tarjotaan lxvfs:n poistoa, johon en haluaisi ryhtyä.

https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1656309
https://superuser.com/questions/1142269/some-file-permissions-have-under-lxc-is-this-a-feature-or-a-sign

/var/lib/lxcfs:ää ei joka tapauksessa kannata varmuuskopioida, koska se sisältää vain /proc-tiedostojärjestelmää muistuttavan näkymän kernelin tietorakenteisiin ja suodatetun näkymän containereiden tiedostojärjestelmiin. Siellä ei ole mitään palautettavaa.

Löysin tuon ensimmäisen linkin myös mutta siinä ei oikein tarjottu mitään ratkaisua, joten ohitin sen melko nopeasti.
Superuser linkki oli uusi tuttavuus mutta siinäkin vain todettiin kyseessä olevan bugi, joten ei apuja sieltä...

/var/lib/lxcfs:ää ei joka tapauksessa kannata varmuuskopioida, koska se sisältää vain /proc-tiedostojärjestelmää muistuttavan näkymän kernelin tietorakenteisiin ja suodatetun näkymän containereiden tiedostojärjestelmiin. Siellä ei ole mitään palautettavaa.

Joo. Taidan tässä vaiheessa excludata /var/lib/lxcfs hakemiston.
Täytynee tutkia asiaa siinä vaiheessa uudelleen jos tutustun noihin lxc:n tai lxd:n.

[nm]

Joo. Taidan tässä vaiheessa excludata /var/lib/lxcfs hakemiston.
Täytynee tutkia asiaa siinä vaiheessa uudelleen jos tutustun noihin lxc:n tai lxd:n.

/var/lib/lxcfs:n excludaus on järkevin ratkaisu silloinkin, kun oikeusbugi korjataan. Eihän /proc- tai /sys-tiedostojärjestelmääkään varmuuskopioida, koska se on virtuaalinen, eikä levyllä sijaitsevaa fyysistä dataa.

Sitten kun otat containerit käyttöön, niiden imaget varmuuskopioidaan erikseen tai ladataan suoraan jostain pilvipalvelusta. Ajossa olevissa containereissa taas ei yleensä säilytetä varmuuskopioitavaa dataa, vaan tietokannat ym. containerin elinkaaren yli säilytettävä data sijaitsee isännän puolelta liitetyissä hakemistoissa, jotka voit sitten varmuuskopioida tavalliseen tapaan tai tietokantaspesifeillä työkaluilla.

[retu]

En nyt tiedä tuosta nimenomaisesta pulmasta, mutta pisti silmään että kopioit /var/backup hakemistoon.

Hetkinen... mistäs sellaiseen päätelmmän päädyit?
Tuossa rsycn komennossahan on tallennuskohteena: /usr/backup/

Juuh! Väitinkö jotain muuta?