Dodih, tuleepahan testattua että tuleeko tosta dedupista mitää käytännön hyötyä. Pistin siirtymään uudelle zfs poolille, missä on seuraavat ominaisuudet enabloitu, kaiken datan jota ei ole backupattu pilveen. Mietin pitkään teenkö mirrorille (vaatisi 2 x saman kokoiset levyt + en ole hommaamassa uusia levyjä nyt), joten pienellä riskillä mennään että ennen raudan vaihtoa sekä nykyinen 4 levyn pakka lahoaa + että tämä ylimääräinen levy lahoaisi. Mutta ihan kaikkeen ei ole rahaa ja tärkeät tiedot on anyway pilvessä turvassa.
Koodi:
sudo zpool create backup \
/dev/disk/by-id/wwn-0x5000c5009e5fe989-part1
sudo zpool add -f backup cache /dev/disk/by-id/ata-Samsung_SSD_840_EVO_1TB_S1D9NSAF631461J-part1
sudo zfs set xattr=sa backup
sudo zfs set acltype=posixacl backup
sudo zfs set compression=lz4 backup
sudo zfs set atime=off backup
sudo zfs set relatime=off backup
sudo zfs set dedup=on backup
sudo zfs create backup/2020-01-11
sudo chown -R $USER. /backup/2020-01-11
Pilvitiedolle tein jo testin ja siinä tuli 1.39 kertainen dedup käyttöaste samoilla asetuksilla, joten nyt isommalla datasetillä (- cloud backup, koska siihen ei tarvii koskea, sen voi aina ladata takaisin levylle pilvestä).
Aloitin syncronisaation uusilla komennoilla (koska uudelleen käytettävä ja voi päivittää tilanteen nopeammin tulevaisuudessa).
Koodi:
#Snapshottaus
sudo su -
zfs snapshot source/dataset1@2020-01-11_dataset1
zfs snapshot source/dataset2@2020-01-11_dataset2
# Listaa snapshotit
zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
source/dataset1@2020-01-11_dataset1 x,xxM - xx,xxT -
source/dataset2@2020-01-11_dataset2 x,xxM - xx,xxT -
# Kopioi poolista toiseen
time zfs send source/dataset1@2020-01-11_dataset1 | zfs receive backup/dataset1 &&\
time zfs send source/dataset2@2020-01-11_dataset2 | zfs receive backup/dataset2
Edit: Jaha, tossa saattaa hetki mennä, välillä tiedostonsiirto tipahtaa n. 1MB/s nopeuteen normaalista n. 100-120MB/s. Tämä on tyyppillistä zfs:lle kun on liian vähän keskusmuistia ja hidas cpu (vaikka l2arc onkin auttamassa). Kaikki koneen huikeasta 7,72GB keskusmuistista on käytössä ja roottilevyn (samsung 850 pro) swapistakin on 4GB/16GB käytössä...
Edit2: Syy vanhan pakan tuhoamiselle on tämä 2017 huhuillun ominaisuuden puute...
[WIP] raidz expansion, alpha preview 1 by ahrens · Pull Request #8853 · zfsonlinux/zfs
Edit3: Ei taida 24h riittää ekan datasetin kopiointiin. No kunhan se on valmis, niin aloitan backup datasettien siirron jonka pitäisi parantaa dedup ratiota (enimmäisten satojen gigojen jälkeen dedup on 1.11x ja compressioratio on 1.03x)...
Keksiikö joku paremman komennon tilanteen tarkkailuun? Nyt joutuu ajamaan 3 komentoa että saa sortattua toisen parametrin mukaisesti...
Koodi:
clear;zfs get used ${ZDATASETS};\
zfs get available ${ZDATASETS};\
zfs get compressratio ${ZDATASETS};\
zpool list
Edit4: Enpä keksinyt muuta kuin tämän...
Koodi:
clear;zfs get used,available,compressratio ${ZDATASETS}|head -n1;\
zfs get used,available,compressratio ${ZDATASETS}|sed '1d'|sort -k2,2;\
zpool list
Edit5: Pudotin rsyncin pois kopioinnista kun zfsstähän löytyy komennot jo itsestään jotka huolehtii myös tulevaisuuden incremental synkistä (niin ei tarvii tehdä miljoonaan kertaan initial synkkiä poolien välillä). Kätsyä, kannattaa joskus vähän googlailla ja lukea manuaalia.
Edit6: Tässä uutta rautaa odotellessa pistin vanhalla raudalla tuulemaan (ja nyt pitää odotella ties montako päivää). Eli siirtelen pilvibackupit omalle datasetille (compressio ja dedup päällä nyt), henkilökohtaiset backupit dedupille ja uudelleen järjestely, mutta mountpointit pysyy samana. Seuraavaksi pitää katsoa onko joku kirjoittanut jo hyvät systemd/cronjob scriptit jolla saa tehtyä tunnin, päivittäisen, viikottaisen, kk ja vuoden snapshot rotaatiot.
Jos ei ole, niin teen itse, mutta luulisi noin yleisen toimenpiteen joku jo tehnyt. Esim. 7pv tunnin snapshotit talteen, sitten 30 pv:ltä pv snapshot tallessa, ja sitten 12kk 1kk snapshot tallessa tms...
Edit7: Nyt löytyi paras komento siirrolle. Nyt myös mahdollista siirrot kun sain yhden ison datasetin jaettua useampaan pienempään kun järkevöitin pakan käyttöä. Dedup tekee kyllä nykyisestä raudata ihan kauhean käyttää, kun kaikki loppuu kesken ja siirrot ja tiedostojen poistot muodostuu ihan kamalan hitaaksi. Mutta nyt kun symlinkit otti isompaan käyttöön ja siirsi eri datat eri dataseteille, niin yleisestä verkkojaostakin tuli järkevämpi.
Eli stuktuuri muuttui nyt näin:
Koodi:
# Poolin rakenne
source/dataset_public # Jaettu kaikille. Ei deduppia
source/dataset{2..xx} # Henkilökohtainen verkkojako jonne backupit, compress + dedup
source/dataaset_cloud # Pilveen tallennettava tärkeä tieto, compress + dedup. Symlink source/dataset_public/dataset_cloud
# Näin voi helposti symlinkillä jakaa yhteiseen datasettiin näkeyvyyttä ja
# voi samalla pitää henkilökohtaiset jaot erilllään yhteisestä paikasta.
# Aikaisemmin kaikki oli samassa, mikä tarkoitti että quotat yms. meni
# vaikeaksi jos piti lohkoa.
# Onneksi tässä tietojärjestelmässä kaikki on vain
# helpompaa vrt. NTFS/ext4/btrfs.
# Eka varmuuskopio
sudo time zfs send source/dataset1@2020-01-12_dataset1 | pv | sudo zfs receive target/dataset1 &&\
sudo time zfs send source/dataset2@2020-01-12_dataset2 | pv | sudo zfs receive target/dataset2 &&\
# ...
sudo time zfs send source/dataseXX@2020-01-12_datasetXX | pv | sudo zfs receive target/datasetXX
# Jos target on tarpeeksi iso, niin voi myös ottaa ihan kaikesta
# backupin kerralla yhdellä komennolla:
sudo time zfs send -rn source@2020-01-12_all| pv | sudo zfs receive target
# Deltan siirto
sudo time zfs send -i
source/dataset1@2020-01-13_dataset1 | pv | sudo zfs receive target/dataset1 &&\
sudo time zfs send -i source/dataset2@2020-01-13_dataset2 | pv | sudo zfs receive target/dataset2
