@kiniu, mam taką samą konfigurację jak Ty i też od czasu do czasu włączam backup. I też VPN uruchamia się z backaupa, bo jest tam mocniejszy procek (0,4GHz do 1.6 GHz), zresztą czuję to podczas transmisji VPNem, mam symetryczne łączę 25/25.

Lokalnie jeśli chcę się dostać do zasobów odpalam komendę WOL i korzystam (w 95% to cobian co jakiś czas odpala skrypt na windowsie)

Zdalnie jest trochę więcej roboty, backup stoi na *uxie.

1. Utworzyłem usera na routrze, który jedyne co może to odpalić komendę wol oraz iptables oraz basha. SU/SUDO organiczne do maksimum. Dość mocno ograniczony user.
2. Uruchomiłem usługę knockd na interface WANowskim, który
- zapisuje  IP z którego uderzałem do lokalnego pliku
- otwiera port z flagą trzymania połączenia na którym stoi ssh na kilkanaście sekund, po czym je zamyka na nowe połączenia
3. SHH przyjmuje tylko uwierzytelnianie z klucza (login/passwd zabronione) i pozwala na 1-go usera w czasie, klucz przesada, bo aż 4098 bit
3.5. To też już będzie przesadą, ale można coś stylu fail2ban postawić dla bezpieczeństwa na otwartym porcie SHH (oraz VPN)
4. Wbija się user vpn do SHH (via putty, uruchomiony ze skryptu profil, który ma za zadanie zalogować się do ssh i wywołać inny skrypt)
5. Inny skrypt otwiera na n-minut porty VPNa dla wskazanego IP.  Po co tak? A bo pukanie można przechwycić, lekka paranoja, ale przezorny zawsze ubezpieczony
6. Logowanie do VPNa
7. Na razie manualne, ale odpalam inną sesję putty (skrypt), który loguje się przez VPN już jako root i po prostu odpala inny skypt, który w przeciągu minuty zabija połączania z wskazanego IP. Jesli zapmnę, to i tak punkt nr. 5 zrobi to automatycznie.

Trochę zakręcone, ale działa dość dobrze. To będzie już schiza, ale planuję zaszyfrować dysk na backapie kluczem, który będzie dostarczony po zalogowaniu się do VPNa, na razie nie mam na to czasu, chętnie posłucham czy to ma sens i jak to zrealizować.

PS. Na kliencie androidzie też śmiga

Chciałbym odświeżyć temat, mam takie coś:

Dec 16 20:48:49 OpenWrt kern.crit kernel: [87381.110000] EXT4-fs error (device sda1): ext4_find_entry:935: inode #117: comm ash: reading directory lblock 0
Dec 16 20:48:50 OpenWrt kern.crit kernel: [87381.200000] EXT4-fs error (device sda1): ext4_find_entry:935: inode #120: comm df: reading directory lblock 0
Dec 16 20:48:50 OpenWrt kern.crit kernel: [87381.210000] EXT4-fs error (device sda1): ext4_find_entry:935: inode #120: comm df: reading directory lblock 0
Dec 16 20:48:50 OpenWrt kern.crit kernel: [87381.220000] EXT4-fs error (device sda1): ext4_find_entry:935: inode #120: comm df: reading directory lblock 0
Dec 16 20:49:17 OpenWrt kern.crit kernel: [87408.200000] EXT4-fs error (device sda1): ext4_find_entry:935: inode #130: comm ash: reading directory lblock 0
Dec 16 20:49:17 OpenWrt kern.crit kernel: [87408.590000] EXT4-fs error (device sda1): ext4_find_entry:935: inode #126: comm ash: reading directory lblock 0

Zrobiony extroot na /dev/sda1 i w związku z tym mam pytanie, bo nie wiem gdzie leży problem.

Pendrive podłączony bezpośrednio do portu USB w TP-LINK 1043ND v1 - 2 dni działa bez zarzutu
Pendrive podłączony przez aktywny hub (z podłączonym i nie zasilaczem ) 1 dzień i w/w log
Pendrive podłączony przez aktywny hub + USB_HDD (z podłączonym zasilaczem ) 1 dzień i w/w log

Czy może to być wina huba? Nie wiem czy hub (sterownik/mod) jest jakoś konfigurowalny w linuxie, jeśli tak czy można coś zmienić?

i to jest problem - pc, na którym był linux ma uszkodzony dysk, stąd chcę go podnieść tą metodą
I brakuje mi pliku grub.pxe plus plików standardowo zanadujących się w lokalizacji /boot/grub

Znalazłem już to wcześniej, ale w OpenWRT nie mogę znaleźć pakietu do zainstalowania 
W normalnym (tj nie okrojonym) na pewno by się to udało...

sudo apt-get install mtd-tools
sudo modprobe -v mtd
sudo modprobe -v jffs2
sudo modprobe -v mtdram total_size=256000 erase_size=256
sudo modprobe -v mtdchar
sudo modprobe -v mtdblock

EDIT:  Znalazłem instrukcję, działa pod OpenWRT
http://www.gentoo-wiki.info/JFFS2/Mounting

root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 000ed800 00010000 "kernel"
mtd2: 006e2800 00010000 "rootfs"
mtd3: 002e0000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 007d0000 00010000 "firmware"
mtd6: 002df000 00001000 "/dev/loop0"
root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    2.9M      2.7M    200.0K  93% /
/dev/root                 4.0M      4.0M         0 100% /rom
tmpfs                    14.3M    704.0K     13.6M   5% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock3            2.9M      2.7M    200.0K  93% /overlay
overlayfs:/overlay        2.9M      2.7M    200.0K  93% /
/dev/sda1                27.9G     14.2G     13.7G  51% /mnt/sda1
/dev/mtdblock6            2.9M      1.3M      1.5M  47% /mnt/sda1/root/flash/a
root@OpenWrt:/#

z analizą kodu jądra będzie trudno

Ale poruszyłeś ważny temat - obecnie nie mam czasu na zabawy sprzętem, ale cały wątek powstał po to, aby mdt3 zastąpić innym obrazem.

Czy wobec tego, że mój spreparowany obraz mtd3 jest mniejszy od obecnie zajmowanej przestrzeni, czy to nie wykrzaczy się?  Spreparować tak obraz overlay'a aby pasował co do bita do mtd3 jest dla mnie technicznie trudną rzeczą (jeśli w ogóle możliwe).  Dlatego pytam, czy po ewentualnym wgraniu nowego obrazu taki znacznik jest w obrazie jffs2, czy system sam go tworzy? A jeśli utworzy to będzie niezagospodarowane miejsce pomiędzy mtd3, a mtd4, tak?

@secam7 - ale kernel jest jest za rootfs, pomiędzy rootfs_data i trzeba byłby jakoś poprzesuwać obszary pamięci. Twoja metoda też dobra, ale w powodów w/w wymienionych nie bawię się w to.

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 0010e254 00010000 "kernel"
mtd2: 00ec1dac 00010000 "rootfs"
mtd3: 00c40000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 00fd0000 00010000 "firmware"

PS. Hipotetycznie - mtd0-mdt5 to jest logiczny podział, czy też można manipulować ich wielkością? Np. więcej dać do mtd3, a zabrać odpwiednio z mdt2?

Ja widzę podział tak:
mdt0 - lepiej nie ruszać - bootloader
mod1 - mtd3 - czy ilości tych obszarów można zmieniać? Załóżmy, że skompilowałem sobie mały kernel, resztę chce oddać na roofs i rootfs_data - mogę tak zrobić?
mod4 - rozumiem, że to dane dla radio i lepiej nie ruszać
mtd5 - co to?

nie wiem a gdzie to mogę sprawdzić?

@pepe2k - TL-WR1043ND v1 (mogę powiedzieć, że od zakupu ~2 lata temu wg półkowych cen w MM jego wartość wzrosła, na półkach też v1 )

@Cezary - dlatego przed wgraniem dodam co trzeba, rozmiar się zwiększy, ale to już po weekndzie. Wybiorę dd, bo wydaje się łatwiejsze, z mtd nie miałem w zasadzie do czynienia. Swoją drogą dlaczego miałby się zbuntować? Zajrzałem do podręcznik i za bardzo nie rozuemim tych parametrów, pomożesz w wytłumaczeniu:

man mkfs.jffs2:

Naprawdę nikt nie potrafi mi pomóc i wytłumaczyć jak wrzucić utworzony obraz overlay'a JFFS2 do /dev/mtdblock3 na działającym (lub nie) OpenWrt?