cron job to copy config backups?

[NJMorf]

I'm trying to create a simple cron job and I can't get the command right. I'm trying this:

cp '/var/db/system/configs-3bc724bbb18d493585697320a07060e7/FreeNAS-11.1-U6 (caffd76fa)' '/mnt/volume_2/Cloud/Neil/Documents/FreeNAS_Config_Backups/'

but when I test the command in the shell (as root), it fails with a "no such file or directory" message referring to the source directory. The source path was copied directly from the command line, so it's definitely correct. I've also tried it with backslashes to escape the space and brackets (because they were added automatically when I copied the path) and that doesn't make a difference either, though surely that shouldn't be necessary if the paths are enclosed in quotes?

I don't see how this could be a problem with the file paths, so is it a permissions issue? The source is on my boot drives (2x mirrored USB sticks), so root should have access, right? The destination is in a dataset on one of my volumes, and it's already set for all users/groups/guests to have full read/write access (I'm new to FreeNAS, so I'm not trying anything fancy with permissions, and the server shouldn't be accessible outside of my home LAN).

Assuming I can get this command to work, I was planning on just sticking it into a simple cron job running once a day to dump any/all files in that directory to my cloud, and therefore to multiple other devices. I probably need to tweak it to work unattended, but I'll worry about that later. Can anyone advise me how to fix this?

Thanks in advance.

 

[joeschmuck]

You should really do a Google search for "freenas copy config script" and see what materializes. A lot of people have already created scripts that work very well.

 

[danb35]

The source is on my boot drives (2x mirrored USB sticks)

It shouldn't be--it's part of your .system dataset, which should be on your pool. .system should never be on a USB boot device (if you boot from a SSD, it's less problematic, but it still means that a boot device failure will lose all your logs, config backups, and other stuff).

Your problem is that you're trying to copy a directory as though it were a file, which isn't going to work. And I'm not sure why you'd be doing that anyway, as you're taking a backup of a backup. If you want to keep copies of the "live" database, it's at /data/freenas-v1.db. Copy that wherever you like, on whatever schedule you like. Or realize that FreeNAS itself has been keeping its own configuration backups since 9.10 was released, so you don't need to do it yourself any more.

 

[kdragon75]

I still do a cron backup and keep versions indefinitely. Never hurts to have a copy of a copied copy.

 

[danb35]

Never hurts to have a copy of a copied copy.

It doesn't, but why do it that way when it's so much simpler to just copy from the source?

 

[Chris Moore]

I'm trying to create a simple cron job and I can't get the command right. I'm trying this:

Take a look at these scripts:

Github repository for FreeNAS scripts, including disk burnin
https://forums.freenas.org/index.ph...for-freenas-scripts-including-disk-burnin.28/

 

[NJMorf]

I'd seen a number of scripts and a (large) number of threads about them in here. Some of the threads/scripts seemed to suggest that they hadn't been updated to work with current versions of FreeNAS, and the script I did try (Spearfoot's, as linked in Chris's post above this one) refused to run for some reason that I lack the knowledge to determine.

I found reference in another thread pointing out that the system already takes copies of the config and suggesting that there's little point in reinventing the wheel, so I tried the simplest approach of just copying the files out of this pre-existing backup, which is apparently held on the boot media. A simple copy should suffice, either overwriting or skipping the copies that have already been copied across, but regardless: nothing's going to work if the system won't/can't find the file path.

For reference, this is the error message I get when trying to run Spearfoot's script:

Code:

save_config.sh: line 2: $'\r': command not found
save_config.sh: line 4: $'\r': command not found
save_config.sh: line 8: $'\r': command not found
save_config.sh: line 11: $'\r': command not found
save_config.sh: line 15: $'\r': command not found
save_config.sh: line 18: $'\r': command not found
save_config.sh: line 20: $'\r': command not found
save_config.sh: line 22: $'\r': command not found
save_config.sh: line 24: $'\r': command not found
save_config.sh: line 104: syntax error near unexpected token `)'
'ave_config.sh: line 104: `  ) > ${logfile}

None of that makes much sense to me, not least because apart from line 104, every error relates to a blank line in that script. I have no idea why the system takes exception to these empty lines.

 

[danb35]

which is apparently held on the boot media.

Again, no, it isn't, unless you've put your .system dataset there--and if you have, you should move it.

 

[NJMorf]

Again, no, it isn't, unless you've put your .system dataset there--and if you have, you should move it.

OK, I may have misunderstood where it was stored (and I haven't changed anything from a default installation), but regardless, the path I put in my original post is, as far as I am aware, correct and certainly contains a series of dated .db files that would appear to be nightly backups. So I'm led back to my initial problem: why can't the cp command work with the given path?

 

[danb35]

why can't the cp command work with the given path?

Because (for the second time) you're trying to copy a directory as though it were a file. That won't work.

 

[NJMorf]

Sorry, I seem to have failed to add that I'd also tried with * and *.* wildcards at the end of the path, to no effect. I didn't realise that cp apparently doesn't adhere to that standard. Using the -R switch seems to make it find the path/files and do what I wanted.

And I'm not sure why you'd be doing that anyway, as you're taking a backup of a backup. If you want to keep copies of the "live" database, it's at /data/freenas-v1.db. Copy that wherever you like, on whatever schedule you like. Or realize that FreeNAS itself has been keeping its own configuration backups since 9.10 was released, so you don't need to do it yourself any more.

I assumed that the backups would go somewhere on one of the volumes in my system. I further assumed that should I lose my boot media entirely, I would lose access to those volumes, or at least easy access. I thought that a simple copy of those backups to a cloud location would suffice to make dated, sequential copies of them them available with the least amount of fuss. Was I wrong?

 

[danb35]

I further assumed that should I lose my boot media entirely, I would lose access to those volumes, or at least easy access.

I guess that depends on what you mean by "easy access." Install FreeNAS to fresh media, import your pool, and all your data will be there. Copy off your config file (I like scp for this, as you don't need to set up any sharing protocols--it only needs SSH access), upload through the web GUI, and you're back in business. I don't see that this is any more fuss than pulling the latest backup off your cloud storage and uploading it, but I guess that's a matter of opinion.

 

[NJMorf]

Fair enough, it sounds simple enough. I was having problems getting NextCloud to sync the files anyway, probably permissions again.

For reference, where exactly does FreeNAS store these backups (physically, not the file path)? I understood that no OS data is stored on the pool disks, hence my assumption that the backups must be on the boot media, given that the boot USB sticks are the only other storage in my system. Looking here implies it must default to the first (non-boot) volume created in the system, but that I could move it anywhere, including on the boot media. Of course, doing so would surely mean losing the config backups (and whatever else) along with the boot media in the event of failure.

 

[danb35]

For reference, where exactly does FreeNAS store these backups (physically, not the file path)?

In the .system dataset, which is wherever you put it. By default, it's put on the first data pool you create, but you can change that through the GUI.

I understood that no OS data is stored on the pool disks

More precisely, none of the OS itself is stored on the pool; it's all on the boot device. Logs and other data are stored, by default, on the pool.

including on the boot media. Of course, doing so would surely mean losing the config backups (and whatever else) along with the boot media in the event of failure.

Correct.

 

[NJMorf]

Righto. So my takeaway from all this is:

1. I don't really need to take any additional config backups, the system already does so
2. The backups are stored in the system dataset (which doesn't show up in the Volumes tab), defaulting to the first pool/volume, having whatever resilience that pool has.
3. Losing the boot media shouldn't cost me my config backups, because by default they're not stored on the boot media anyway
4. In the event of complete boot media failure, it's relatively simple to create new media, import the existing pools, then find the most recent good backup from within the system dataset and apply it.

Cool, ta muchly.

 

[danb35]

Right. There was a feature request for a new installation to automatically find the latest config backup in the .system dataset on a pool, and offer to import it. I thought that was supposed to have been implemented, but I can't say I've ever seen it. @Ericloewe? Do you recall this? I think we were discussing it at one point.

 

[Ericloewe]

A few things:

• I did file a feature request, not for an automatic use of backups from the system dataset, but a manual restore backup option.
• The feature request was closed as implemented.
• The feature was not implemented in the GUI (I'm not sure exactly what was done).
• The feature request should be open again.

 

[Chris Moore]

I'd seen a number of scripts and a (large) number of threads about them in here. Some of the threads/scripts seemed to suggest that they hadn't been updated to work with current versions of FreeNAS, and the script I did try (Spearfoot's, as linked in Chris's post above this one) refused to run for some reason that I lack the knowledge to determine.

I found reference in another thread pointing out that the system already takes copies of the config and suggesting that there's little point in reinventing the wheel, so I tried the simplest approach of just copying the files out of this pre-existing backup, which is apparently held on the boot media. A simple copy should suffice, either overwriting or skipping the copies that have already been copied across, but regardless: nothing's going to work if the system won't/can't find the file path.

For reference, this is the error message I get when trying to run Spearfoot's script:

- code - snip

None of that makes much sense to me, not least because apart from line 104, every error relates to a blank line in that script. I have no idea why the system takes exception to these empty lines.

You didn't follow the directions. Instead of reinventing the wheel, why don't you ask questions about why the existing script isn't working for you, because it should, it works for me and you have the same revision of FreeNAS.