Can you look at memory usage during copy? Maybe its just your drive speed and the first gb gets cached.
You can also write manual partition tables without swap. The swap space in the size of the memory is needed for suspend mode, if you dont need it just format a root fs in ext as / and if you install gpt (uefi) another partition as /boot/
Than 2 and 3 only.
The structure is the one, that was already in the old filesystem. I am also pretty sure, if the Dir1sums file would not have been there, that md5deep would have thrown an exception.
You should restart the whole thing from the beginning.
1. Use rsync (dont forget -a) and copy the old data onto the new disk.
2. Use diff -r oldDisk newDisk to check if the files were all copied
3. Use md5deep to check if all files that got copied were copied correctly
And thats about it.
Its all working perfectly fine! You just misunderstood something there. You created the file Dir1sums in your /root/ which contains the checksums of your source folder. You compared them to your destination folders and did not get any errors. Now do the same thing with diff -r, if this does not prompt anything, your copy is correct.
One time you check for file structre, the other time for checksums in identicaly named and placed files.
You were not able to find dir1sums in your filesystem just because you named it Dir1sums instead. Nothing going wrong, often refered to as an layer 8 problem, but you did not break anything, so its fine.
Ok, so it is all fine and working as expected. The other command df -hT had an additional space. I wrote this on an android device, where the keyboard adds spaces all the time...
It is much simplier than anything else. You just ignored the case sensitive part. It is names Dir1sum, not dir1sum. Filesize is also ok now, propably just an issue of your viewing gui.
As you ignored my requests in editing the file and altering a checksum, I just tested it myself using this:Bash
This is the resulting output:
As you can see, md5deep is working as I suggested earlier on. It has output if checksums are different, but not, if the file does not exist at all.
Judging from this, your test scenario is not working. If you copied the files, you can check if they are correct with md5deep. To check, if the file structre is the same you need to do something in addtion.
This here would work:
diff -r sourceDir destDir
It will display all differences in file structure (names only, not looking at data inside the files).
This one here works for raid 0 too, but use the backup flag!
It may indeed make sensce to remove two drives out of the raid 1, so you can use them to rebuild a raid 1,0. On the other hand, growing will create a lot of disk usage and so the propability of failure, in this case without redundancy, therefore grows too.
So what you want to do us growing a Raid0. It is possible, but not exactly secure.
Especially if there osis a master and a slave node.
I think the gui is already shipped in the omv frontend.
Right, I already thought so.
I know a rpi is not a good device for nas, but I could set up and run some tests on a rpi2 and rpi3, if this is of any help.
Right, unmount the partition first and copy it to an image via dd (or ddrescue). Than make a copy of the image file (with checksums) and than work on that copy. If you break anything, just make anothet copy of the original dd image.
This is the downside of point and click usage of rsync, mistakes are made easily. You always need an additional layer of backups from a nas, if you want to be sure to not loose data.
I have two in location seperated storage systems that I keep versionized backups of my private nas in, also making sure to not connect both at the same time for protection against crypto attacks. For my professional systems I got a quite complex backup strategy, which would be too expensive for my personal data. From my personal experience in privat and proffesional environments, most data are lost due to small but impactfull mistakes, just like yours, while people tend to only protect against hardware failure.
You can/should use rsync (this is what it was written for and has been reliably used for 20 years in professional environments). If bandwidth is becomming an issue, use compression in addition.
Ok, I am not sure if you are still trying to fix this, but if so some further advice.
In general keep in mind, that the file naming on modern filesystems is case sensitive (different with fat type fs).
What makes me wonder is that your Dir1sums has a 0b size, but you can open this and read lines. Is this mounted async, some tmpfs or some fuse fs (like mergefs) ?
Please provide output of the following:
df - hT
ls -ltra /root/
Do you know how to navigate trough a fs in terminal? ls and cd are the most important commands. Also use tab when writing, this way you get some autocompletition and you dont have to write the filenames all by your own with the possibility of mistakes there.
It looks like your config.xml has a wrong codec. Copy it and try to recreate one. Be careful with the new config file, dont put anything inside that overwrites important stuff.
The filesystem is key sensitive. Dir1sums != dir1sums.
One of many reasons why I hate Linux. It seems to suffer from all these stupid small things that should be common sense. I have selected right time zone and the right time. That should be the end of that.
You do realize that the time protokoll is much more enhanced than in windows? There is a very good reason, that GNU/Linux sets utc inside the bios. Your system than looks at his timezone settings and calculates the time. If this isnot working your system got brokem severly before. It is also a necessarity in professional environments to differentiste between thy sxstem and the bios clock. So if you dont write changes to hwclock, you loose changes with reboot. Or you set the timezone but missed to update the clock, I highly advice ntpd, which takes care of most things.
Well, I am not too sure what is happening there, can you cat the dir1sums please?
You can still use rsync with checksums in a second copy.
The second copy will only actually alter files, if a checksum differed.
Md5deep however should be very very reliable, so propably something else is going on. Thinking about it, I am not sure, if it posts missing files at all. Try altering one md5sum in dir1sums and let it check against the files. There are a lot of usecases, where it makes sense to only check existing files, not for the existence itself.
As always, if you oversimplify, it is simply wrong. I know thta this seems to be common sense in modern internet communities, but this is mainly due to the reason tht there is a severe lack of knowledge.