Backup to USB To Take Home

[cflnet]

Forgive me if this has already been answered, I did search but could not find an answer to my exact question.

I am looking to have an external USB rotation for additional backup. I would like to be able to plug in a USB drive, have a scheduled backup run to the drive, unplug the drive at the end of the day to take home. If possible I would like to rotate drives this way but I am not sure the first part is even possible yet. The key thing about this is I need it to be automated. I need the user to only have the responsibility of swapping the drives nightly.

I was thinking I could bypass the TrueNas GUI and just do some CRON jobs to script this but it appears that even just mounting the drive is limited through the TrueNas install. So is there another way to do this, either through the GUI or through manually scripting it?

Any help would be greatly appreciated!

 

[Arwen]

I use external disks for backups. My method is described in;
TrueNAS Resources - How to: Backup to local disks
This does not cover your exact use case, but, you can easily modify the concept to meet your needs.

 

[cflnet]

I might play with that in testing but I wouldn't want that in production for my client. I was hoping for a more "official" way but it doesn't seem to be the case unfortunately.

 

[Arwen]

No, their is no official locally attached disk backup solution as far as I know. All the "official" methods are through network copies, like ZFS replication. In theory, you can replicate to another pool on the same NAS server. But, their is no support for automatically importing the pool, performing the replication and exporting the pool.

 

[Patrick M. Hausen]

• ZFS replication works locally.
• You can have a ZFS pool on a USB drive - multiple drives for a single pool might pose a problem, but a single drive is generally OK.
• You can have as many ZFS pools of the same name as you like as long as you connect/import only one at a time.
• The replication tasks refer to pools by name, not by any fancy ID.

So just do:

• Create e.g. "MyBackupPool" on a single USB HDD.
• Export the pool, create another one of the same name on a second HDD. Rinse and repeat.
• Connect one HDD, import the pool in the UI.
• Create a nightly replication task of the data you want to backup.
• Every office day:
  • Export the pool from the UI.
  • Disconnect HDD.
  • Connect different HDD.
  • Import the pool from the UI.
• Let the nightly replication run.

Done - daily backup schedule with rotating media.

Alternatively: create differently named pools for each day of the week or similar and create multiple replication tasks. But all of this can be achieved fully supported with standard configuration from the UI. Only thing to keep in mind is: export - disconnect - connect new - import.

 

[cflnet]

• ZFS replication works locally.
• You can have a ZFS pool on a USB drive - multiple drives for a single pool might pose a problem, but a single drive is generally OK.
• You can have as many ZFS pools of the same name as you like as long as you connect/import only one at a time.
• The replication tasks refer to pools by name, not by any fancy ID.

So just do:

• Create e.g. "MyBackupPool" on a single USB HDD.
• Export the pool, create another one of the same name on a second HDD. Rinse and repeat.
• Connect one HDD, import the pool in the UI.
• Create a nightly replication task of the data you want to backup.
• Every office day:
  • Export the pool from the UI.
  • Disconnect HDD.
  • Connect different HDD.
  • Import the pool from the UI.
• Let the nightly replication run.

Done - daily backup schedule with rotating media.

Alternatively: create differently named pools for each day of the week or similar and create multiple replication tasks. But all of this can be achieved fully supported with standard configuration from the UI. Only thing to keep in mind is: export - disconnect - connect new - import.

Thank you for the info but the intention is for a non-technical user to be able to just swap the drives. I would need this fully automated, which it sounds like it is not doable through TrueNas. If we had a tech on site daily, that'd be fine but the user doesn't have the ability/want to deal with doing any tasks other than plugging in the drive and unplugging it.

The suggestion above to do it over network share is what we had come up with as well and seems to be the route we are going to go. It should be fairly easy to script the backup and "eject" the drive automatically. That way the user can just swap the drives and not have to go into the TrueNas console for anything.

 

[NugentS]

Backup to Storj instead? Or some other cloud service

 

[Patrick M. Hausen]

If we had a tech on site daily, that'd be fine but the user doesn't have the ability/want to deal with doing any tasks other than plugging in the drive and unplugging it.

You need a tech to login to a UI, select Storage > Pools > Export, then Storage > Pools > Add ... ok. You do you. I consider these tasks dead easy.

 

[Davvo]

You need a tech to login to a UI, select Storage > Pools > Export, then Storage > Pools > Add ... ok. You do you. I consider these tasks dead easy.

I would not give the keys of a production system to a non-technician employee.

 

[Samuel Tai]

Thank you for the info but the intention is for a non-technical user to be able to just swap the drives. I would need this fully automated, which it sounds like it is not doable through TrueNas. If we had a tech on site daily, that'd be fine but the user doesn't have the ability/want to deal with doing any tasks other than plugging in the drive and unplugging it.

The suggestion above to do it over network share is what we had come up with as well and seems to be the route we are going to go. It should be fairly easy to script the backup and "eject" the drive automatically. That way the user can just swap the drives and not have to go into the TrueNas console for anything.

I run something like this for my own server. It does require creating some cron job tasks using TrueNAS API calls, and replication tasks.

Let's say your user plugs in the disk on Monday morning at 9 AM. This disk will have a ZFS pool on it, which can be mounted via a cron job at 9:30 AM via midclt call pool.import_pool '{ "guid": "<ZFS GUID of external pool>" }'. (You can find the GUID via zpool get guid <name of external pool>.)

Then you replicate datasets from your server to the external disk every M-Th at 8 PM.

On Friday, around 3 PM, you run another cron job task to export the external pool via midclt call pool.export "<GUID of external pool>". Your user can then unplug the external disk, and take it home with them for the weekend. Rinse and repeat next week.

 

[Samuel Tai]

Correction on the pool.export call: The parameter is the "id" of the pool in the pool table from midclt call pool.query | jq, not the GUID. From my experiments, this increments by 1 at every pool.import_pool. Your export cron job task will need to pull out the appropriate "id" value from the pool.query before running pool.export.