etrash2000

@tkaiser, I was actually planing to use btrfs as an underlying fs due to the error checking, even though I don't not know most of all its benefits yet. I will try to read up when I have time and develop the setup over the next few months. I might buy another board or use the old Rasberry Pi with an external USB disk to play around with. Concerning your comment about archive, could you please explain it, as I dont think you mean TAR (which I never liked). Concerning snapshots, I'm using snapshots with my virtual box in order revert the system to a known state. Admittedly, it is a very nice feature to learn more about how it works on btrfs. @ Skygod, it is a good idea worth checking. You are more than welcome to give the details and scripts.

I'm using Jessie. i dont think chksum in fs can really do anything about deliberate change by accident/virus/worm so i need to track which version on 4-5 hdds is correct. I had an "accident" once where several files were present but the all content were gone (0B). From fs point of view, there was no problem but obviously the photos were gone. Sent with Tapatalk

This is true but unfortunately, my knowledge stops at 2006 . I will try to read up and do a test run with btrfs to see if it is simple enough. I currently waiting on the harddrives which are delayed 2 weeks. Can btrfs tools do the following: * re-evelate the checksum of the file on the disk without rewriting the file. * export the checksum to an external database in order to keep historical data so i can know when the change/corruption occurred.

Thanks TKaiser, I was hoping that you would respond since I read most of your comments on the Bananian forum and I knew that you had switched. The reply is as I expected (which is why I posted the question here instead of at the Bananian forum) but I would like to have it confirmed by someone which has used both systems before I commit any work on this small project. Concerning the layout of the project, I have not decided yet on any specific protocol yet. I will later post about my ideas later when I have tried a few things and when I more time. In the mean time, if anyone of you have some ideas or experience with backups then feel free to keep this tread alive (if it is allowed the forum rules). The things I want is * Local daily backup of my laptop. Revision control and check-sum control are required. Monthly checksums will go into a local database. * Local offline backup to an external USB-disk, probably will commit this manually 2-4 times a year. * Remote backup, daily or weekly. Probably with rsync to local server. Checksum control here as well. * E-Mail daily progress from both local and remote servers, preferably encrypted. * Move rootfs to ram in order to avoid the SD card once the system is up and running. * I have not decided on how to obtain my local/remote IP address, probably DynDNS but emails could be an option. Background info: I have about 300GB of photos and home videos which I do not want to loose. Those damn cameras are just getting bigger and bigger image sizes . Thanks again.

Yes, i have seen that page. I also know that both of them are using Debian repositories, so I assume that the difference is in how the kernel is built. I did a very rudimentary test run with both Bananian and Armbian. The throughput with sftp were similar for both at 10MB/s over WiFi, mainly limited by CPU on the board. This is fine with me since my internet upload is 10mbps to the remote site. My goal is to build a long-term backup solution for my photos, home videos and some documents, totaling about 300-400GB. I don't want to touch the system after first launch (with exception of updates). My hope is Armbian which support more plattforms will be more stable and secure than Bananian as it could attract more users. Btw, i'm om Jessie, vanilla image.

it is the M1. http://www.armbian.com/banana-pi/

Hi all, I bougth a couple for Bananian Pi in order to set up (a NAS +) Local Backup + Remote Backup. I'm in the phase of deciding on distribution. What are the main differences between Armbian and Bananian?

Igor, isn't this uncesseraly complicated as dd will take whatever boot loader is on the old sd-card. You can (at least in the old days when I did it last time) with these steps. First some notes: 1. Have a running Linux/Unix/Mac system other than the system on the original SD card. Any Linux Live CD will work as they all have dd. 2. Your new SD card (on /dev/sda) must be identical or larger than your old SD card (on /dev/sdb). 3. You must unmount your SD cards during these steps (or mount them as read-only). THIS IS IMPORTANT. 4. I use sdX as a generic name here, your devices will probably be named differant. Use lsblk to find out the names. Run the following codes. # Copy old SD to you computer as a image. SD card must be unmounted before this code. dd if=/dev/sdb of=/path/to/image bs=512 # Copy image to new SD card, ​# Note sda is just a generic name here to indicate your new card to differentiate it from your old card. ​# It will actually be the same block device in both lines of code as you are using the same card reader. dd if=/path/to/image of=/dev/sda bs=512 If you have a computer with 2 SD card readers then you can combine both line to a single line of code as dd if=/dev/sdb of=/dev/sda bs=512 If you want to copy the boot-loader of a device then use the following code ​# Copy bootloader (Master boot record, MBR, https://en.wikipedia.org/wiki/Master_boot_record) dd if=/dev/sdb of=/path/to/mbr bs=512 count=1 Further notes: * Note that I am using the block device /dev/sda and not the partition /dev/sda1 on that device. * If your new card is larger than your old card then you migth need to resize your partitions afterwords. You can use parted/gparted or whatever is on your Linux system. I'm sure armbian have some tools for that. Maybe Igor could help on this. * If you new SD card is smaller than you can still perform these task but with more steps. Let me know if this is the case. * Boot loader and information about your partitions used to be within the first 512 bytes of a device. I'm not sure how u-boot works so you may need to verify the last code.