ZFS Backup windows machine to a FreeBSD machine

M

mefizto

Greetings all,

I have a FreeBSD based backup server. To backup Windows machine, I mount a /backup/Win_7 share on the Windows machine and use FreeFIleSync for backup. I do this manually, since when a name of a file is changed, the FreeFileSync does not recognize this, deletes the file with the original name and baks-up the file with the new name.

I was looking at automated backup tools, but it seems that the options are programs like Amanda, Bacula, Bareos, which appear to have a rather complicated configuration, and I have been unable to determine, whether they will have the same problem with the filenames.

Am I overlooking an easier option?

On a different subject, for a future backup of the backup server, is there a comparison of the many different snapshot based tools?

Kindest regards,

M
 
Why not use rsync? It's available for windows. Create a batch file (or whatever they're called nowadays) and run task scheduler with it.
You could even tar or 7zip the file(s) and just copy them to the backup directory on FreeBSD.
 
Hi diizzy,

thank you for the reply. When I looked at Syncthing, my understanding was that it is a synchronization program. But, based on your recommendation I will check whether it can be used for backup.

Hi mark_j,

thank you for your reply. There is no native rsync for Windows 7.

Kindest regards,

M
 
If you just want to clone a single copy of the files and then keep that copy up to date, robocopy /MIR works pretty well on Windows to copy files from the local machine to a Samba share on the network. The first run takes a while, but subsequent runs only copy changes and finish quickly. I have also tried cwRsync but have always run into errors on Windows; traditional rsync on Linux and FreeBSD has never given me any trouble. You could also wrap Robocopy in a script to maintain several full snapshots, but that might quickly start to use a lot of space.

I currently use ShadowProtect to back up full and differential backups of the C: drive onto a spare E: drive, then use a Powershell script to Robocopy those files over to a Samba share on a removable drive in the FreeBSD backup server.

Wikipedia has a pretty good list of backup software in case it helps.

I have also done some basic testing with restic but am not using it full-time yet. Here's how to create a dummy file, back it up, restore it and verify it afterwards.

Code: 
C:\Users\ccammack> mkdir C:\test & cd C:\test
C:\test> powershell $out = new-object byte[] 1048576; (new-object random).nextbytes($out); [io.file]::writeallbytes('random.bin', $out)
C:\test> restic init --repo \\BACKUP\desktop\restic-repo
[...]
created restic repository df32e0f92d at \\BACKUP\desktop\restic-repo
[...]
C:\test> restic -r \\BACKUP\desktop\restic-repo --verbose backup c:\test
[...]
snapshot 96f75888 saved
C:\test> restic -r \\BACKUP\desktop\restic-repo restore latest --target c:\test
[...]
restoring <Snapshot 96f75888 of [c:\test] at 2020-06-08 22:39:50.69799 -0700 PDT by desktop\ccammack@desktop> to c:\test
C:\test> certutil -hashfile c:\test\random.bin MD5
MD5 hash of file c:\test\random.bin:
16 93 6d 4b d5 2a b5 d6 82 1d e5 fd 37 67 4c fe
[...]
C:\test> certutil -hashfile c:\test\c\test\random.bin MD5
MD5 hash of file c:\test\c\test\random.bin:
16 93 6d 4b d5 2a b5 d6 82 1d e5 fd 37 67 4c fe
[...]
 
Greetings all,

I was wondering, if I am not thinking about the backup from a wrong point-of-view. Here is the workflow that I am contemplating. (I am assuming, without any loss of generality) first backup at time t1)

1. At the time t1 mount the FreeBSD share /backup/Win_7 on the Windows machine;
2. Synchronize the content of the data from the Windows machine to the share;
3. Dismount the share;
4. Take a snapshot of the share;
5. At the time t2 repeat steps 1-3;
5. Take an incremental snapshot with respect to the snapshot from step 4.

If this is correct, can you recommend a good (and simple) snapshot management tool? There are a lot of them, and for a beginner, it is difficult to understand the differences.

Kindest regards,

M
 
pdumpfs

This is a program that is in both ports and has a windows install. I have used it for years on both windows and freebsd. It maybe something that will do what you want.

http://0xcc.net/pdumpfs/ is the website.

sysutils/pdumpfs

You will need to setup your own automation such as a ps script or shell, but the program will do a sliding window on your backups. The webpage will have addition information.

jda
 
I highly recommend using shadow volumes for your backup, so when during your backup process files change the backup is in a consistent state. So in your case I would make a shadow copy and then backup the respective directories of that volume using restic
 
Hi jda,

thank you for your recommendation.

Hi rootbert,

if I understand correctly, shadow volume is necessary when a content of the copied entity may change. So, if the backup is schedulet at time when no such activity takes place, is it necessary? Or is it just a good practice?

Kindest regards,

M
 
mefizto said:
1. At the time t1 mount the FreeBSD share /backup/Win_7 on the Windows machine;
2. Synchronize the content of the data from the Windows machine to the share;
3. Dismount the share;
4. Take a snapshot of the share;
5. At the time t2 repeat steps 1-3;
5. Take an incremental snapshot with respect to the snapshot from step 4.
Click to expand...

What's a little strange about this workflow to me is trying to use a simple one-copy file clone method (rsync, FreeFileSync, Robocopy) to clone the current state of the Windows machine to the backup server, then snap-shotting the backup sever. I would lean toward using better backup software on the Windows client that can do its own differential backups and keep a snapshot history on its own (restic or something else, or commercial). That way you could test the Windows side independently by backing up to a local USB drive, then change the destination to the backup server share after everything else works properly.

Either way, if you use ZFS on the FreeBSD sever, snapshots are included.
 
Hi ccammack,

thank you for the criticism of the workflow.

The reason for using a simple one-copy file clone method is that this will result in flat files, thus no dedicated tool will be necessary for recovery. I understand that this will result in larger space required, but given that I intent to backup three machines, two of which have similar content (workstation and laptop), I am not much concerned about it.

And the clone needs to be snapshotted, otherwise it would not work as a backup, but a synchronization.

Kindest regards,

M
 
Well, I do some advertising of... myself :)
Try zpaqfranz
github.com

GitHub - fcorbelli/zpaqfranz: Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife for the serious backup and disaster recovery manager. Ransomware neutralizer. Win/Linux/Unix

Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife for the serious backup and disaster recovery manager. Ransomware neutralizer. Win/Linux/Unix - fcorbelli/zpaqfranz
github.com github.com

You can do much more than you ever dream with a single command
As an alternative you can use zpaq, it is in the ports, but it is very old version

Code: 
zpaqfranz a /tmp/mygoodbackup.zpaq /backup/Win_7

That's it
You will get, at every run, a "snapshot" (a versioned backup) of the data, inside a single deduplicated and compressed (/encrypted if you want) archive

If you have more than one (mounted-smb-dir) with somewhat duplicated data
Code: 
zpaqfranz a /tmp/mygoodbackup.zpaq /backup/Win_7 /backup/Win_10 /backup/Win_11

A snippet (in this example v-server windows machine @ 10.0.0.240, user utente, share condivisioni) just to be sure to get the share mounted before the backup
Code: 
df | grep -q /backup/Win_7
if [ $? = 0 ]; then
        else
                /bin/date +"%R ----------SISTEM:  try to mount"
                /usr/sbin/mount_smbfs -N -I 10.0.0.240 //utente@v-server/condivisioni /backup/Win_7
fi

and on /root/.nsmbrc
Code: 
[default]
Workgroup=MYWORKGROUP

[V-SERVER]
addr=10.0.0.240

[V-SERVER:UTENTE]
password=mypasswod
 
mefizto said:
if I understand correctly, shadow volume is necessary when a content of the copied entity may change. So, if the backup is schedulet at time when no such activity takes place, is it necessary? Or is it just a good practice?
Click to expand...
its good practice, but if you are sure the data you are going to backup won't change I see no problem if you do not snapshot the filesystem
 
You must log in or register to reply here.
Back
Top