0

I am having problem with a backup solution for a small company.

Outline

One NFS Share (on a linux server in network)
5 HDDs (Mon - Fri)

Need to change them every day (attached via USB-Docking-Station),
then mount them from a client on the network and copy data.
Share is always in the same location, each HDD is always mounted under this share.


Problems:
1) HDDs can't be umounted safely, device always busy once a client connected to the share. Even when there is nothing going on between server and client)

2) After changing HDD (example: swap out monday-hdd, put in tuesday-hdd) the client can't stay connected and use the newly put in HDD immediatly, I have to disconnect the share and reconnect it.

Is there a solution that would let me
a) just switch the disk every day on the server and the client without forced umount -l?
and
b) enable the client to just keep working with the connected share, without having to reconnect?

Improve this question
  • Take a look at virtual tape libraries. Depending on your backup solution it might be able to use it. – Gerald Schneider May 2 '18 at 13:20
  • Looks interesting, thanks for the suggestion. Will look into this. – Thersites May 3 '18 at 0:58
0

Perhaps have a different share for each day and insert 2 drives simulataneously at switchover time

Insert Tuesday Drive Mount as tuesday folder Start NFS-Tues Share Have client side script to umount and mount the new days share (same local mount) Client is now using new drive Stop NFS-Mon Share Umount monday drive, unplug, and place in storage

Rinse and repeat? Should be able to script that relatively easily (minus physical moves)

Improve this answer
  • Thanks for the input. Unfortunately it's a single slot dock and upgrading is not an option. – Thersites May 2 '18 at 13:01
0

Having an NFS share for backups is generally a bad idea. It is a persistent connection (or equivalent), the backup is available live on the filesystem and the NFS client needs to be maintained, as you describe above.

Why not use bareos or just ssh your backup over?

If using ssh, I would create directories in each HDD named "mon", "tue", and so on, depending on which day of the week the disk is meant for.

The client can then ssh the backup over to the disk:

tar ... | ssh $backupuser@$backupserver "cat > /mnt/$(date +%a|tr A-Z a-z)/$HOSTNAME.tar"

That way, if the wrong disk (or no disk) is mounted, the day-of-week directory will not exist and the backup will fail, instead of overwriting the previous backup. Your monitoring (or cron job) should alert you about it if properly configured.

If you really, really cannot avoid NFS, at least consider having the NFS share mounted just before the backup and unmounted immediately afterwards. This is a flaky solution though. For example, if the backup script gets killed, the next day's backup will fail mounting the NFS share.

Setting up bareos is probably a much better solution in the long term.

Improve this answer
  • Thank you for the input. Indeed, ssh could be feasible, haven't thought about it to my dismay. I wasn't aware that NFS could be a bad solution for this. I kind of just expected it to be what I was looking for. Too bad. – Thersites May 3 '18 at 0:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.