Need some help setting up backup solution. Brand new OMV NAS on Raspberry Pi 3B+, 32Gb microSD Card, 4TB WD RED NAS + 4TB WD RED NAS

    • OMV 4.x
    • Resolved
    • [restore] which involves getting on the command line), that may make rsnapshot unsuitable for beginners.
      The commandline can be avoided just the way you avoid it to create the backup in your guide:
      Create a sheduled task with a rsync command.
      rsync -av
      /srv/dev-disk-by-label-EXT402/rsnapshot/daily.0 /srv/dev-disk-by-label-EXT401/restore


      another option to save space on the destination drive:
      with --link-dest it will link to existing files on the source drive rather than having the files twice:
      rsync -av
      /srv/dev-disk-by-label-EXT402/rsnapshot/daily.0 /srv/dev-disk-by-label-EXT401/restore -
      -link-dest /srv/dev-disk-by-label-EXT402

      Then, restore is not harder than backup.
      Alternatively, the Restore can be done with WinSCP.

      And: there are many supportive and helpful people in the forum and elsewhere.
      If the Family-Hotos are lost, even a newbie will be able to restore with that help -and if it is by paying 50$ to a pro. With the rsync option, it would need a professional data recovery company and around1000$

      Greetings,
      Hendrik

      The post was edited 1 time, last by henfri ().

    • Those are practical suggestions. I'm not a fan of linking the destination drive back to the source drive (or a new source), in that two disks would be doing what one did originally, but it would work.

      I'll look at them to see if a process can be sifted out that makes sense to new users. Like you, I'd rather see new users have some depth in their back up. (Actually, I prefer backing up to a second host, which could be a backup server as well, but that's another topic.)
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • @henfri
      I do not understand your rant against rsync. Both, rsync and rsnapshot have advantages and scenarios where they are best used. Imho rsync is excellent for data that doesn't change often (especially media files like movies, photos and music). Rsnapshot is excellent for documents cause of the versioning.

      henfri wrote:


      A real live example from some days ago:
      My wife cleaned up here Documents folder including the folder "Photobooks". She thought it was a duplicate and deleted it. But it was not.
      She told me about this in the evening - after the weekly backup had run.

      So, if I had the simple rsync solution, the content of here Documents folder would have been mirrored onto the backup drive -without the folder "Photobooks". Everything would have been gone.
      But I do not have this simple solution, but a versioned backup using rsnapshot. This way I could use the backup from last week and restore from that.
      That's plain wrong. By default rsync doesn't delete in the target folder. So if you delete files in your source, they are still existing after your weekly sync in your target folder. If you want another behavior you have to knowingly set this option. Your wife would still have her photos in her backup folder.

      henfri wrote:


      If the Family-Hotos are lost, even a newbie will be able to restore with that help -and if it is by paying 50$ to a pro. With the rsync option, it would need a professional data recovery company and around1000$
      With rsync you have a plain copy of your source. So why would I have the need for a data recovery company for 1000$?
      If you're not familiar with the console, just make your backup folder a smb share and you can handle the data from your win box. No compressed stuff or containers... a simple copy. If you're not afraid of the console cp source target and you're done.

      Don't get me wrong, I'm new to OMV and for sure I don't intend to offend you or anyone else in this forum. I have to say this cause I know my english is far from perfect and always sounds somehow harsh.
      Still rsync works pretty smooth for me.

      Thomas
    • flmaxey wrote:

      Those are practical suggestions. I'm not a fan of linking the destination drive back to the source drive (or a new source), in that two disks would be doing what one did originally, but it would work.

      That's not what I intended.
      I intended to
      1) create a new folder with the restored backup (as I do not overwrite the source)
      -but this would require twice the space (one for the files that are 'still on the source drive' and one for the restored backup
      2) for that reason link the files that are identical between the source and the restored backup.

      That's what the above command should do.

      Stramm wrote:

      @henfri
      I do not understand your rant against rsync. Both, rsync and rsnapshot have advantages and scenarios where they are best used.
      I have no objections against rsync. As long as it is used from within rsnapshot ;)
      I see no disadvantage of rsnapshot. If one just ignores everything but daily.0 it's identical to pure rsync.

      Imho rsync is excellent for data that doesn't change often (especially media files like movies, photos and music). Rsnapshot is excellent for documents cause of the versioning.
      I disagree -sorry. Today I found that some configuration files in /etc/ had nonsense in them. The file modification date was January. I was able to restore them from my backup.
      These are no documents that need versioning or similar.

      henfri wrote:

      A real live example from some days ago:
      My wife cleaned up here Documents folder including the folder "Photobooks". She thought it was a duplicate and deleted it. But it was not.
      She told me about this in the evening - after the weekly backup had run.

      So, if I had the simple rsync solution, the content of here Documents folder would have been mirrored onto the backup drive -without the folder "Photobooks". Everything would have been gone.
      But I do not have this simple solution, but a versioned backup using rsnapshot. This way I could use the backup from last week and restore from that.
      That's plain wrong. By default rsync doesn't delete in the target folder. So if you delete files in your source, they are still existing after your weekly sync in your target folder. If you want another behavior you have to knowingly set this option. Your wife would still have her photos in her backup folder.
      I am referring to the command from flmaxeys manual. In that he uses the --delete command. And I agree to use it for the usecase he describes.


      henfri wrote:

      If the Family-Hotos are lost, even a newbie will be able to restore with that help -and if it is by paying 50$ to a pro. With the rsync option, it would need a professional data recovery company and around1000$
      With rsync you have a plain copy of your source. So why would I have the need for a data recovery company for 1000$?
      Because I deleted the files in my source by mistake and because the "delayed-mirror" backup approach often suggested here would also mirror the deletion process.

      If you're not familiar with the console, just make your backup folder a smb share and you can handle the data from your win box. No compressed stuff or containers... a simple copy. If you're not afraid of the console cp source target and you're done.
      No. Backups must be versioned.


      Don't get me wrong, I'm new to OMV and for sure I don't intend to offend you or anyone else in this forum.
      Don't worry. You don't offend me.

      Still rsync works pretty smooth for me.
      I can imagine that. But there are quite probable cases in which a plain 'delayed mirror' is just not sufficient.

      I have listed two already.
      Another that happened to me: Bit-Rod. One of my harddrives had a fault which damaged the file-system. Lots of files had "." characters instead of the actual data in them. I did not notice for weeks and I would have had this in my backup as well. The bad files would have overwritten the good ones.

      So, that's three now. Judge your self whether this is unlikely enough. And check, whether your strategy can cope with these scenarios.
      If one of the answers is 'no', I suggest to work on a versioned backup.

      Greetings,
      Hendrik
    • Users Online 2

      2 Guests