RN214 refuses to take snapshots

[VolkerB]

Hi!

After factory-resetting and reinstalling my RN214 (check out https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Admin-page-unavailable-after-cancel... for details) it seems that the "smart snapshot" option is not working anymore. I don't remember doing anything differently in comparison to last time (i. e. enabling hourly smart snapshots for home folders, allowing SMB snapshot access for everyone via the directory /home/<username>/snapshot), yet the system summary shows 0 (zero) snapshots and so does the "Recover Files" dialog. Of course all directories /home/<username>/snapshot are empty.

It seems that there is no option to manually take a snapshot for home folders but thanks to BTRFS and data compression I have snapshots available for the /temp share as well and they seem to work as expected:

06 Nov 2021 10:39:39		Snapshot: Snapshot Test was successfully deleted from share or LUN Temp.
06 Nov 2021 10:39:19		Snapshot: Snapshot Test was successfully created for share or LUN Temp.
06 Nov 2021 09:44:02		System: ReadyNASOS background service started.

Firmware 6.10.5 Hotfix 1 if that matters. Is there anything I could do for further investigation? Thanks a bunch for your support!

Volker

P.S.: I have activated disk spindown after 20 minutes but allow spin up for scheduled snapshots. So that shouldn't be the problem either.

[VolkerB · Accepted solution]

---

@VolkerB wrote:

[...] snapshots (neither smart nor custom, no matter what schedule) did not seem to work anymore for the home shares of all users. Manual and automatic snapshots for other shares not related to individual users worked fine. There was no issue with insufficient space (no snapshot pruning taking place) [...] So I have created a new user "test" with all default settings in the "Users" group. [...] for user "test" automatic snapshots are actually taken successfully, while at the same time, no snapshots for user "volker" are stored even though he is sharing the same schedule. As it happens to be, [X] Allow snapshot access was enabled for volker and [ ] Protection was disabled, user "test" had it the other way round. [...]

Currently, I'm running a test with various combinations of (dis)allowing snapshot access and en-/disabling the protection feature, (de)activating bit rot protection and compression for the other shares to find out what exactly spoils the fun here.

The tests have completed. Conclusion:

If you don't activate the [X] Protection option in the Home Folders > Settings > Snapshot Access for all the users where snapshots should be taken, no schedule whatsoever is going to work. Everything else (Bit-rot-protection and compression for shares, snapshot access for individual users, the type of schedule and whether you want snapshots even if nothing changed) does not matter.

So if some Netgear dude is listening: Perhaps this critical relationship could at least be made more clear in the manual or probably even a warning displayed if the admin deviates from a setting that implicitely disables snapshots.

HTH & Greets,

Volker

[StephenB]

I have two comments on your settings.

1. The "Smart" snapshots never delete the monthly snapshots.  Over time, that will fill the data volume.  While you can go in periodically and deleted the oldest snapshots, it is simpler to switch to "Custom", and set retention.  You can also tell the system not to store snapshots if there are no changes.
2. Making snapshots visible in Windows has an unfortunate side effect - the snapshots are writeable, so files can be deleted by the user (or encrypted by ransomware).  This is a non-started for me - so I allow Windows Previous Version, but I don't allow users to otherwise browse the snapshots.

I'm not sure what's going on in your case.  But I am thinking you might try renaming or or deleting a file in one of the home folders, and see if that triggers a snapshot.  FWIW, I don't use home folders myself - we don't need or want the privacy feature, and they aren't easy to restore from a backup.

[VolkerB]

@StephenB : I think smart snapshots are quite convenient as daily snapshots are automatically promoted to weekly snapshots every Friday and become monthly snapshots at the end of every month. As only monthly snapshots are kept forever and BTFRS just stores the delta, storage issues are unlikely in low traffic situations. In contrast, the classic method just allows specifying a duration or number for snapshot retention.

For snapshot access via SMB and subfolders in the user's home directory, the RN214 allows enabling "protection" (whatever that is, didn't try so far), so I figure the folder is readonly for the user in that case. I want the system to be as close to a nobrainer as possible so the option that users can browse into snapshots using the system/tools they are accommodated to and restore file versions without my help is a big plus.

Using home folders at all facilitates automatic synchronization of local files quite a lot in my case (rsync, robocopy) and I don't want documents specific to the operating system or the particular user to be spread all across the public shares. The latter are for commonly used media only.

Having said that: Smart snapshots in user's home folders used to work fine before (manual snapshots still do), data has been changed many times after I have done a factory reset and rebuilt the NAS. There is nothing totally obvious that I was doing differently since the first setup (with the potential exception of enabling SSH), so this is quite a mistery to me.

I did compare a configuration backup before and after the factory reset (relevant differences were SSH=1 and
TIMEMACHINE_PROTOCOL=SMB vs. TIMEMACHINE_PROTOCOL=AFP in \etc\default\services) but no changes seem causal to the issue. Of course, I can provide more detailed information if necessary, just tell me where to look.

Thanks & greets,

Volker

[StephenB]

What firmware are you running?

---

@VolkerB wrote:

I think smart snapshots are quite convenient as daily snapshots are automatically promoted to weekly snapshots every Friday and become monthly snapshots at the end of every month. As only monthly snapshots are kept forever and BTFRS just stores the delta, storage issues are unlikely in low traffic situations.

Up to you of course.  It was a problem for me.  The "delta" over time adds up - especially in the share where I store my PC backups.

"Custom" is definitely the "no brainer" config for me - it manages my overall space automatically much better.  Back when I was using "smart" snapshots I had to manually delete the oldest monthly snapshots periodically.

FWIW, I've never understood the benefit of the snapshot thinning. It seems to me it just risks deleting the version you want to roll back to.  I much prefer the "only make snapshots with changes" setting in the custom snapshots.

[VolkerB]

---

---

@StephenB wrote:

What firmware are you running?

6.10.5 Hotfix 1 - which, as my device tells me, is the latest stable version.

---

@StephenB wrote:

"Custom" is definitely the "no brainer" config for me - it manages my overall space automatically much better.  Back when I was using "smart" snapshots I had to manually delete the oldest monthly snapshots periodically.

FWIW, I've never understood the benefit of the snapshot thinning. It seems to me it just risks deleting the version you want to roll back to.  I much prefer the "only make snapshots with changes" setting in the custom snapshots.

---

I unfortunately don't quite understand, what "only make snapshots with changes" mean, since the ReadyNAS OS 6.9.3
Software Manual (which seems to be the latest one) doesn't mention it. It could a) mean that I get a snapshot of the entire volume mapped in the /home/<user>/snapshot directory only if at least one file has changed in the entire volume or b) only the delta between the current state and the last snapshot is exposed if - and only if - something has changed. With smart snapshots, a) seems to be the case, I would probably prefer b) but every approach has its benefits. Since this is a feature of BTFRS, you probably don't have a choice and snapshots only contain the delta as "real" data anyway. The rest is just hard(?) links.

But that is all a matter of taste and doesn't solve my problem. So I have disabled disk spindown (the manual claims that for hourly snapshots the disks are never spun up, probably ignoring the menu option [X] Spin up disks to take scheduled snapshots), created a custom hourly snapshot schedule but without the "only make snapshots with changes" option set. This should get me exactly one snapshot per hour.

This is to test my assumption, that on this RN214 and for unknown reasons, automatic snapshots are not working anymore, neither smart ones nor custom ones. Perhaps because some daemon is not running or ill-configured. Just for the records: That box is running a 8TB 2-disk XRAID (so essentially a RAID-1) and it has 2.28TB free space. Snapshot pruning occurs at 90% capacity (I left the option at it's default) which the system is quite far away from. I never ran a defrag/scrub/balance since the reinstall.

For the curious: The reinstall became necessary because of a rsync backup gone wrong with the target disconnected and filling the mount point in the OS partion instead of the USB drive that should have been mounted there which had me ending up with the system volume root's usage at 99% and the admin page being unavailable.

No SSH, no other option. I had a backup of my data though.

Addendum: Several hours have passed, no automatic snapshot(s). Just as I expected. What now? What is blocking that job from running?

[VolkerB]

So I have disabled disk spindown, created a custom hourly snapshot schedule but without the "only make snapshots with changes" option set. This should get me exactly one snapshot per hour and test my assumption, that on this RN214 and for unknown reasons, automatic snapshots are not working anymore, neither smart ones nor custom ones. Perhaps because some daemon is not running or ill-configured. That box has 2.28TB of 8TB free and is running a XRAID. Snapshot pruning occurs at 90% capacity (default). I never ran a defrag/scrub/balance since the reinstall.

After several hours have passed, no automatic snapshot(s). Just as expected.

cron.log:

Nov 07 07:16:03 rn214-volker cron[1911]: (CRON) INFO (pidfile fd = 3)
Nov 07 07:16:03 rn214-volker cron[1911]: (CRON) INFO (Running @reboot jobs)
Nov 07 07:17:02 rn214-volker cron[1911]: (*system*spindown) RELOAD (/etc/cron.d/spindown)
Nov 07 07:17:02 rn214-volker CRON[2807]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

btrfs.log

=== filesystem /data ===
Data, single: total=4.99TiB, used=4.99TiB
System, DUP: total=8.00MiB, used=576.00KiB
Metadata, DUP: total=2.00GiB, used=1.35GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
=== subvolume /data ===
ID 257 gen 72 top level 5 path home
ID 258 gen 2253 top level 5 path .apps
ID 259 gen 12 top level 5 path .vault
ID 260 gen 2255 top level 5 path ._share
ID 265 gen 2254 top level 5 path .timemachine
ID 270 gen 2238 top level 5 path Media
ID 271 gen 1880 top level 270 path Media/.snapshots
ID 274 gen 2222 top level 5 path Software
ID 275 gen 1881 top level 274 path Software/.snapshots
ID 276 gen 2235 top level 5 path Temp
ID 277 gen 2237 top level 276 path Temp/.snapshots
ID 278 gen 122 top level 5 path .purge
ID 279 gen 2249 top level 257 path home/volker
ID 280 gen 2247 top level 257 path home/admin
ID 281 gen 2247 top level 257 path home/anja
ID 419 gen 1880 top level 5 path Backup
ID 421 gen 1880 top level 419 path Backup/.snapshots

auth.log

Nov 07 07:17:02 rn214-volker CRON[2806]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 07 07:17:02 rn214-volker CRON[2806]: pam_unix(cron:session): session closed for user root
Nov 07 07:23:14 rn214-volker apache2[2373]: pam_unix(frontview:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.0.0.20  user=admin
Nov 07 07:23:16 rn214-volker apache2[2373]: pam_unix(frontview:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.0.0.20  user=admin

(no idea what this authentication failure is about)

mounts.log

udev on /dev type devtmpfs (rw,noatime,nodiratime,size=10240k,nr_inodes=187927,mode=755)
devpts on /dev/pts type devpts (rw,noatime,nodiratime,mode=600,ptmxmode=000)
/dev/md0 on / type ext4 (rw,noatime,nodiratime,data=ordered)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime,nodiratime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime,nodiratime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime,nodiratime,size=516500k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,blkio)
mqueue on /dev/mqueue type mqueue (rw,noatime,nodiratime)
configfs on /sys/kernel/config type configfs (rw,noatime,nodiratime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,noatime,nodiratime)
/dev/md127 on /data type btrfs (rw,noatime,nodiratime,nospace_cache,subvolid=5,subvol=/)
/dev/md127 on /apps type btrfs (rw,noatime,nodiratime,nospace_cache,subvolid=258,subvol=/.apps)
/dev/md127 on /home type btrfs (rw,noatime,nodiratime,nospace_cache,subvolid=257,subvol=/home)
tmpfs on /home/admin/snapshot type tmpfs (rw,noatime,nodiratime,size=4k)
tmpfs on /data/home/admin/snapshot type tmpfs (rw,noatime,nodiratime,size=4k)
tmpfs on /home/anja/snapshot type tmpfs (rw,noatime,nodiratime,size=4k)
tmpfs on /data/home/anja/snapshot type tmpfs (rw,noatime,nodiratime,size=4k)
tmpfs on /home/volker/snapshot type tmpfs (rw,noatime,nodiratime,size=4k)
tmpfs on /data/home/volker/snapshot type tmpfs (rw,noatime,nodiratime,size=4k)

BTRFS-related in processes.log

S root      1060     2  1060  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-worker]
S root      1062     2  1062  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-worker-hi]
S root      1063     2  1063  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-delalloc]
S root      1064     2  1064  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-flush_del]
S root      1065     2  1065  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-cache]
S root      1066     2  1066  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-submit]
S root      1067     2  1067  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-fixup]
S root      1068     2  1068  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-endio]
S root      1069     2  1069  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-endio-met]
S root      1070     2  1070  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-endio-met]
S root      1071     2  1071  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-endio-rai]
S root      1072     2  1072  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-endio-rep]
S root      1073     2  1073  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-rmw]
S root      1074     2  1074  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-endio-wri]
S root      1075     2  1075  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-freespace]
S root      1076     2  1076  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-delayed-m]
S root      1077     2  1077  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-readahead]
S root      1078     2  1078  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-qgroup-re]
S root      1079     2  1079  0    1  60 -20     0     0 rescue 07:15 ?        00:00:00 [btrfs-extent-re]
S root      1899     2  1899  0    1  80   0     0     0 cleane 07:16 ?        00:00:00 [btrfs-cleaner]
S root      1900     2  1900  0    1  80   0     0     0 transa 07:16 ?        00:00:00 [btrfs-transacti]

readynasd.log

Nov 06 09:43:35 rn214-volker readynasd[2158]: readynasd log started
Nov 06 09:43:35 rn214-volker readynasd[2158]: readynasd started. (restarted=0)
Nov 06 09:43:54 rn214-volker readynasd[2158]: Using fan mode: quiet
Nov 06 09:44:02 rn214-volker readynasd[2158]: ReadyNASOS background service started.
Nov 06 09:49:12 rn214-volker readynasd[2158]: Protocol 'daap' is stopped
Nov 06 10:39:19 rn214-volker readynasd[2158]: Snapshot Test was successfully created for share or LUN Temp.
Nov 06 10:39:39 rn214-volker readynasd[2158]: Snapshot Test was successfully deleted from share or LUN Temp.
Nov 06 10:40:49 rn214-volker readynasd[2158]: Snapshot Test was successfully created for share or LUN Temp.
Nov 06 10:43:40 rn214-volker readynasd[2158]: Snapshot Test was successfully deleted from share or LUN Temp.
Nov 06 11:04:21 rn214-volker readynasd[2158]: The system is shutting down.
Nov 06 11:05:03 rn214-volker readynasd[2158]: Exit main thread by SIGTERM.
Nov 06 11:05:03 rn214-volker readynasd[2158]: readynasd is halted.
-- Reboot --
Nov 07 07:16:11 rn214-volker readynasd[2160]: readynasd log started
Nov 07 07:16:12 rn214-volker readynasd[2160]: readynasd started. (restarted=0)
Nov 07 07:16:29 rn214-volker readynasd[2160]: Using fan mode: quiet
Nov 07 07:16:39 rn214-volker readynasd[2160]: ReadyNASOS background service started.
Nov 07 07:16:49 rn214-volker readynasd[2160]: Automatic disk spin-down disabled.
Nov 07 07:19:00 rn214-volker readynasd[2160]: Protocol 'daap' is stopped

snapper.log

Config: 0, subvolume: /data/Backup
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 |       |      | root |         | current     |         

Config: 4, subvolume: /data/Media
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 |       |      | root |         | current     |         

Config: 6, subvolume: /data/Software
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 |       |      | root |         | current     |         

Config: 7, subvolume: /data/Temp
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 |       |      | root |         | current     |         

system.log

Nov 07 07:23:13 rn214-volker apache_access[2372]: 10.0.0.20 "GET /admin/ HTTP/1.1" 401
Nov 07 07:23:14 rn214-volker apache2[2373]: pam_unix(frontview:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.0.0.20  user=admin
Nov 07 07:23:16 rn214-volker apache2[2373]: pam_unix(frontview:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.0.0.20  user=admin
Nov 07 07:23:18 rn214-volker apache2[2377]: [auth_basic:error] [pid 2377] [client 10.0.0.20:63234] AH01617: user admin: authentication failure for "/admin/": Password Mismatch, referer: http://rn214-volker/admin/
Nov 07 07:23:20 rn214-volker apache2[2582]: [auth_basic:error] [pid 2582] [client 10.0.0.20:59991] AH01617: user admin: authentication failure for "/dbbroker": Password Mismatch, referer: http://rn214-volker/admin/
Nov 07 07:23:20 rn214-volker apache_access[2372]: Suppressed 2 duplicate messages
Nov 07 07:23:20 rn214-volker apache_access[2372]: 10.0.0.20 "POST /dbbroker HTTP/1.1" 401
Nov 07 07:23:37 rn214-volker apache_access[2372]: ::1 "OPTIONS * HTTP/1.0" 200
Nov 07 07:24:41 rn214-volker connmand[2044]: ntp: adjust (slew): -0.000328 sec
Nov 07 07:25:20 rn214-volker apache_access[2372]: 10.0.0.20 "GET /admin/ HTTP/1.1" 401
Nov 07 07:25:26 rn214-volker apache_access[2372]: 10.0.0.20 "POST /dbbroker HTTP/1.1" 401
Nov 07 07:25:39 rn214-volker apache_access[2372]: 10.0.0.20 "GET /ispdb.xml?_dc=1636266339745 HTTP/1.1" 200
Nov 07 07:26:12 rn214-volker apache_access[2372]: ::1 "OPTIONS * HTTP/1.0" 200
Nov 07 07:26:51 rn214-volker nmbd[2051]: [2021/11/07 07:26:51.851691,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
Nov 07 07:26:51 rn214-volker nmbd[2051]:   ***** Samba name server RN214-VOLKER is now a local master browser for workgroup TRUDERING on subnet 10.0.0.22 *****
Nov 07 07:33:13 rn214-volker connmand[2044]: ntp: adjust (slew): +0.005345 sec
Nov 07 07:46:05 rn214-volker apache_access[2372]: 10.0.0.20 "GET /admin/images/system/buttons/btn-question-w.png HTTP/1.1" 404
Nov 07 07:50:17 rn214-volker connmand[2044]: ntp: adjust (slew): +0.002576 sec
Nov 07 08:03:37 rn214-volker apache_access[2372]: ::1 "OPTIONS * HTTP/1.0" 200
Nov 07 08:04:04 rn214-volker dbus[1913]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Nov 07 08:04:04 rn214-volker dbus[1913]: [system] Successfully activated service 'org.opensuse.Snapper'
Nov 07 08:07:21 rn214-volker connmand[2044]: ntp: adjust (slew): +0.008024 sec
Nov 07 08:08:23 rn214-volker dbus[1913]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Nov 07 08:08:23 rn214-volker dbus[1913]: [system] Successfully activated service 'org.opensuse.Snapper'
Nov 07 08:08:24 rn214-volker rnutil[5140]: Failed to get tier from /dev/md0 : 25

... does not look too alarming. At least no failed cron jobs around 08:00:00.

[VolkerB]

... after some fiddling with SSH:

admin@rn214-volker:/etc/cron.d$ ls -la
total 20
drwxr-xr-x  2 root root 4096 Nov  7 07:16 .
drwxr-xr-x 82 root root 4096 Nov  7 07:19 ..
-rw-r--r--  1 root root    0 Sep 27 12:50 frontview-backup
-rw-r--r--  1 root root  102 Jul  4  2012 .placeholder
-rw-r--r--  1 root root   59 Nov  6 11:03 poweroff
-rw-r--r--  1 root root   60 Nov  7 07:16 spindown

root@rn214-volker:/etc/cron.hourly# ls -la
total 12
drwxr-xr-x 2 root root 4096 Sep 22 16:58 .
drwxr-xr-x 82 root root 4096 Nov 7 08:56 ..
-rw-r--r-- 1 root root 102 Jul 4 2012 .placeholder

admin@rn214-volker:/usr/bin$ snapper list
The config 'root' does not exist. Likely snapper is not configured.
See 'man snapper' for further instructions.
admin@rn214-volker:/usr/bin$ snapper list-configs
Config | Subvolume
-------+---------------
0 | /data/Backup
4 | /data/Media
6 | /data/Software
7 | /data/Temp

root@rn214-volker:/# ls -la home
total 4
drwxr-xr-x 1 admin admin 30 Sep 22 16:58 .
drwxr-xr-x 24 root root 4096 Nov 7 08:08 ..
drwx------ 1 admin admin 76 Nov 6 13:44 admin
drwx------ 1 anja users 1354 Nov 6 13:44 anja
drwx------ 1 volker users 412 Nov 6 13:44 volker

Since I'm not familiar with the subtleties of automatic snapshot creation, I don't know if there should be any related cron job existin in either cron.d or cron.hourly. That there is no config root for snapper sounds a bit weird and there could also be an issue with access rights to the users' home directories. So I set up another custom hourly snapshot schedule for /data/Temp (which is rwx for everybody) - so if that fails as well, then I believe there's a generic issue with automatically running the process that should take the snapshot.

Result: In fact the (automatic) snapshot for /data/Temp has been taken successfully:

So it might be a problem with access rights. No idea though where to look...

[StephenB]

What firmware are you running?

---

@VolkerB wrote:

Result: In fact the (automatic) snapshot for /data/Temp has been taken successfully:

---

Have you tried disabling snapshots on one of the problem shares, and then re-enabling them?

There should be configurations files in /etc/snapper/configs (numeric file names) for each share that you might want to look at.

[VolkerB]

---

@StephenB wrote:

What firmware are you running?

6.10.5 Hotfix 1. My box claims that this is the latest stable one.

---

@StephenB wrote:

Have you tried disabling snapshots on one of the problem shares, and then re-enabling them?

Yes. Did not work. The home shares seem to be pretty special in terms of snapshots anyway since you can take manual snapshots. I could delete alle the non-admin users (will probably also nuke their storage) and recreate but that feels like the typical Windows-tip to reboot or reinstall the OS. BTDT, took quite long, no motiviation to do it a 3rd time.

---

@StephenB wrote:

There should be configurations files in /etc/snapper/configs (numeric file names) for each share that you might want to look at.

---

 I'll have a look.

Thanks a bunch,

Volker

[VolkerB]

OK, to summarize: After reverting my RN214 to factory settings and creating home shares for a couple of users, snapshots (neither smart nor custom, no matter what schedule) did not seem to work anymore for the home shares of all users. Manual and automatic snapshots for other shares not related to individual users worked fine. There was no issue with insufficient space (no snapshot pruning taking place), analysis of the logs via SSH and by exporting them from the box did not yield any clues.

So I have created a new user "test" with all default settings in the "Users" group. The first visible difference were with ownership of (sub)directories, where directory "test" for user "test" is owned by the respective user and (sub)directory "Documents" of user "volker" was owned by root. 

root@rn214-volker:/home/test# ls -la
drwx------  1 test  users 46 Nov  8 07:45 .
drwxr-xr-x  1 admin admin 38 Sep 22 16:58 ..
drwxrwxr-x+ 1 test  users  0 Nov  8 07:45 test
-rwxrwxr-x+ 1 test  users  4 Nov  8 07:44 #test.txt

root@rn214-volker:/home/volker# ls -la
drwx------  1 volker users     396 Nov  8 08:10 .
drwxr-xr-x  1 admin  admin      38 Sep 22 16:58 ..
-rwxrwxr-x+ 1 volker users   92508 Oct 22 19:04 20211022_backup.log
drwxrwxrwx  1 root   root   187098 Nov  2 16:57 Documents

That might be due to the way I have restored the backup, i. e. by creating a trivial rsync copy job to copy from the USB3 drive directly attached to the NAS. Since snapshots should be taken by root, I figure that this is not a problem though. And files/folders are rw(x) for UG which should be sufficient. If not, a simple chown -R on the console will do the trick.

It got more interesting after finding out that for user "test" automatic snapshots are actually taken successfully, while at the same time, no snapshots for user "volker" are stored even though he is sharing the same schedule. As it happens to be, [X] Allow snapshot access was enabled for volker and [ ] Protection was disabled, user "test" had it the other way round. I don't think, (dis)allowing snapshot access is the big deal here, so let's have a look at what the manual says for the protection option. Well, ummm, not much: "Snapshots, if used, of content within the home folder are also within the home folder, with the same protection.". So it's probably about Bit Rot protection (copy-on-write) which is available on redundant RAID architectures. As the manual also states "could decrease performance", I have probably switched it off at some point.

Currently, I'm running a test with various combinations of (dis)allowing snapshot access and en-/disabling the protection feature, (de)activating bit rot protection and compression for the other shares to find out what exactly spoils the fun here. Stay tuned - screenshots of the respective menu options attached below.

[VolkerB · Accepted solution]

---

@VolkerB wrote:

[...] snapshots (neither smart nor custom, no matter what schedule) did not seem to work anymore for the home shares of all users. Manual and automatic snapshots for other shares not related to individual users worked fine. There was no issue with insufficient space (no snapshot pruning taking place) [...] So I have created a new user "test" with all default settings in the "Users" group. [...] for user "test" automatic snapshots are actually taken successfully, while at the same time, no snapshots for user "volker" are stored even though he is sharing the same schedule. As it happens to be, [X] Allow snapshot access was enabled for volker and [ ] Protection was disabled, user "test" had it the other way round. [...]

Currently, I'm running a test with various combinations of (dis)allowing snapshot access and en-/disabling the protection feature, (de)activating bit rot protection and compression for the other shares to find out what exactly spoils the fun here.

The tests have completed. Conclusion:

If you don't activate the [X] Protection option in the Home Folders > Settings > Snapshot Access for all the users where snapshots should be taken, no schedule whatsoever is going to work. Everything else (Bit-rot-protection and compression for shares, snapshot access for individual users, the type of schedule and whether you want snapshots even if nothing changed) does not matter.

So if some Netgear dude is listening: Perhaps this critical relationship could at least be made more clear in the manual or probably even a warning displayed if the admin deviates from a setting that implicitely disables snapshots.

HTH & Greets,

Volker

[StephenB]

---

@VolkerB wrote:

After factory-resetting and reinstalling my RN214 (check out https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Admin-page-unavailable-after-cancel... for details) it seems that the "smart snapshot" option is not working anymore.

Is there anything I could do for further investigation? 

---

I am wondering how you recreated the home folders after you did the reset.  Did you restore the config files, and then just do rsync to /data/home with ssh?

Snapshot can only be made on BTRFS subvolumes, and rsync only creates ordinary folders.  If you used the process above, the GUI would think the folders were btrfs subvolumes, but in fact they wouldn't be.

You could use some ssh commands to double-check (btrfs subvolume list ...) and you could also try making a snapshot from ssh (btrfs subvolume snapshot ...)

[VolkerB]

---

@StephenB wrote:

---

@VolkerB wrote:

After factory-resetting and reinstalling my RN214 (check out https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Admin-page-unavailable-after-cancel... for details) it seems that the "smart snapshot" option is not working anymore.

---

I am wondering how you recreated the home folders after you did the reset.  Did you restore the config files, and then just do rsync to /data/home with ssh?

---

No.  I let the RN214 do its thing with formatting/synchronizing the RAID, then created shares for /Media, /Software, /Temp, /Backup using the management GUI and then added the users that should have access. After that, I created a "Backup job" in the management GUI to copy back data from the locally attached USB3-HDD into the relevant shares. No SSH involved.

---

@StephenB wrote:

---

Snapshot can only be made on BTRFS subvolumes, and rsync only creates ordinary folders.  If you used the process above, the GUI would think the folders were btrfs subvolumes, but in fact they wouldn't be. You could use some ssh commands to double-check (btrfs subvolume list ...) and you could also try making a snapshot from ssh (btrfs subvolume snapshot ...)

---

I'm pretty convinced that the entire volume including subvolumes etc. is BTRFS since I exclusively used the RN214's GUI for that. I was just copying back naked data afterwards. Doesn't (re)activating the "[X] Protection" option to bring back snapshots for users' home directories as mentioned in my above post and the fact that snapshots always worked on shared folders of the same volume prove that everything is BTRFS?

BTW, I don't remember having created subvolumes. The system is a bone stock standard setup with a couple of additional shares for data that should be accessible for all users. If there is something I could/should check via SSH to further clarify things - perhaps similar to https://www.tecmint.com/find-linux-filesystem-type/ , I'll be happy to do so.

Volker

[StephenB]

---

@VolkerB wrote:
BTW, I don't remember having created subvolumes.

---

The web ui creates a subvolume automatically when you create a share.  Unfortunately, home folders are treated differently.  The subvolume is created the first time the user accesses the NAS using Windows - not when the user is created in the web ui (or when  restoring the config files).

When you restored the NAS, you needed to access the NAS from Windows using each user's credentials before you ran the backup job - and based on your description, you didn't do that.  The backup job would have created ordinary subfolders in home, and not subvolumes.

This would certainly explain why snapshots aren't working. You can confirm my explanation with ssh by 

root@NAS:~# btrfs subvol list /data | grep home
ID 257 gen 1123683 top level 5 path home
ID 9340 gen 1123683 top level 257 path home/admin

You should see a path for each user in the output.  I don't think you will. 

If I am correct, what you need to do to recover is

1. rename each /home subfolder temporarily
2. access the NAS using each user's credentials from Windows using file explorer.
3. confirm that the subvolumes were created
4. copy the contents of the temporary folders into the appropriate user folders
5. delete the temporary folders.

FWIW, the complexity of restoring home folders when rebuilding the NAS is one reason I've decided not to use them.  I've turned off all sharing protocols in home.  Creating a regular share with restricted access gives you something easier to manage - though the share isn't hidden.  

[VolkerB]

---

@StephenB wrote:

---

@VolkerB wrote:
BTW, I don't remember having created subvolumes.

---

The web ui creates a subvolume automatically when you create a share.  Unfortunately, home folders are treated differently.  The subvolume is created the first time the user accesses the NAS using Windows - not when the user is created in the web ui

That is exactly what I found as well while I was creating the "test" user for my snapshots experiments. You had to log in/mount the directory on the client once to have the directory created.

---

@StephenB wrote:

---

When you restored the NAS, you needed to access the NAS from Windows using each user's credentials before you ran the backup job - and based on your description, you didn't do that.  The backup job would have created ordinary subfolders in home, and not subvolumes.

Not 100% sure if I did that. However... (see below). But I agree that this process is a little counterintuitive and hampers a successful restore quite considerably.

---

@StephenB wrote:

You can confirm my explanation with ssh by 

root@NAS:~# btrfs subvol list /data | grep home
ID 257 gen 1123683 top level 5 path home
ID 9340 gen 1123683 top level 257 path home/admin

I get the following:

root@rn214-volker:/home/admin# btrfs subvol list /data | grep home
ID 257 gen 2306 top level 5 path home
ID 279 gen 2617 top level 257 path home/volker
ID 280 gen 2333 top level 257 path home/admin
ID 281 gen 2307 top level 257 path home/anja
ID 5405 gen 2621 top level 280 path home/admin/.snapshots
ID 5407 gen 2621 top level 281 path home/anja/.snapshots
ID 5410 gen 2621 top level 279 path home/volker/.snapshots

This hopefully means "all is good", all user's home directories are valid BTRFS subvolumes and just enabling the "[X] Protection" option does the trick. I'm seeing snapshots arrive after this so just wanted to make sure I don't create broken/useless ones or fscking up my system in other nasty ways (again).

---

@StephenB wrote:

---

If I am correct, what you need to do to recover is

1. rename each /home subfolder temporarily
2. access the NAS using each user's credentials from Windows using file explorer.
3. confirm that the subvolumes were created
4. copy the contents of the temporary folders into the appropriate user folders
5. delete the temporary folders.

So - despite this probably not being necessary in my case - what you essentially do is let the NAS' OS create the BTFRS subvolumes first (by logging in the respective user) and then move back the data that you have (temporarily) parked elsewhere. Makes sense. Very helpful information indeed.

And, yes, I get the point that creating "regular" shares with appropriate access rights might be more straightforward. However, I sincerely hope that excercises such as completely resetting the system or restoring a backup won't be necessary anytime soon...

Thanks again & greets,

Volker

[VolkerB]

---

@StephenB wrote:

---

@VolkerB wrote:
BTW, I don't remember having created subvolumes.

---

The web ui creates a subvolume automatically when you create a share.  Unfortunately, home folders are treated differently.  The subvolume is created the first time the user accesses the NAS using Windows - not when the user is created in the web ui

That is exactly what I found as well while I was creating the "test" user for my snapshots experiments. You had to log in/mount the directory on the client once to have the directory created.

---

@StephenB wrote:

---

When you restored the NAS, you needed to access the NAS from Windows using each user's credentials before you ran the backup job - and based on your description, you didn't do that.  The backup job would have created ordinary subfolders in home, and not subvolumes.

Not 100% sure if I did that. However... (see below). But I agree that this process is a little counterintuitive and hampers a successful restore quite considerably.

---

@StephenB wrote:

You can confirm my explanation with ssh by 

root@NAS:~# btrfs subvol list /data | grep home
ID 257 gen 1123683 top level 5 path home
ID 9340 gen 1123683 top level 257 path home/admin

I get the following:

root@rn214-volker:/home/admin# btrfs subvol list /data | grep home
ID 257 gen 2306 top level 5 path home
ID 279 gen 2617 top level 257 path home/volker
ID 280 gen 2333 top level 257 path home/admin
ID 281 gen 2307 top level 257 path home/anja
ID 5405 gen 2621 top level 280 path home/admin/.snapshots
ID 5407 gen 2621 top level 281 path home/anja/.snapshots
ID 5410 gen 2621 top level 279 path home/volker/.snapshots

This hopefully means "all is good", all user's home directories are valid BTRFS subvolumes and just enabling the "[X] Protection" option does the trick. I'm seeing snapshots arrive after this so just wanted to make sure I don't create broken/useless ones or fscking up my system in other nasty ways (again).

---

@StephenB wrote:

---

If I am correct, what you need to do to recover is

1. rename each /home subfolder temporarily
2. access the NAS using each user's credentials from Windows using file explorer.
3. confirm that the subvolumes were created
4. copy the contents of the temporary folders into the appropriate user folders
5. delete the temporary folders.

So - despite this probably not being necessary in my case - what you essentially do is let the NAS' OS create the BTFRS subvolumes first (by logging in the respective user) and then move back the data that you have (temporarily) parked elsewhere. Makes sense. Very helpful information indeed.

And, yes, I get the point that creating "regular" shares with appropriate access rights might be more straightforward. However, I sincerely hope that excercises such as completely resetting the system or restoring a backup won't be necessary anytime soon...

Thanks again & greets,

Volker

[Sandshark]

Alternately, you can use the command mkhomedir_helper from ssh to create each user's share instead of logging in using each user's credentials.  You must still rename the current folders first, since there can be no duplicates.

[VolkerB]

---

@Sandshark wrote:

Alternately, you can use the command mkhomedir_helper from ssh to create each user's share instead of logging in using each user's credentials.  You must still rename the current folders first, since there can be no duplicates.

---

I was following @StephenB 's advice and all users' home folders showed up as BTRFS subvolumes. My posting covering that still seems to be in approval though. So that hopefully means all is good and snapshots should work as expected with no side effects as soon as I activate the "[X] Protection" option in the context menu.

You advice with the mkhomedir_helper script is still quite cool. I wonder how you found out about it?

It's been a while since I reset the box and restored the backup - so it could very well be that I tried all users/passwords first and then took care of the data. Lucky coincidence.

Volker

[StephenB]

---

@VolkerB wrote:

I unfortunately don't quite understand, what "only make snapshots with changes" mean

It only makes a snapshot if there's been a change to the main share after the previous snapshot was taken.

[Sandshark]

---

@VolkerB wrote:

---

You advice with the mkhomedir_helper script is still quite cool. I wonder how you found out about it?

Take a look in /usr/bin and you'll find some interesting stuff.  Most have --help available.

[VolkerB]

---

@StephenB wrote:

---

@VolkerB wrote:

I unfortunately don't quite understand, what "only make snapshots with changes" mean

It only makes a snapshot if there's been a change to the main share after the previous snapshot was taken.

---

So if "something" changes in the entire share, then a snapshot is created that comprises all the files and directories of that share where all unchanged file(s) and directory/-ies point to the same location (a hard link probably) and only the changed file(s) and directory/-ies get a new link.

On a more figurative level: For snapshots accessible by the users (mapped to the /home/user/snapshot directory), you would have:

Original state:

/home/user/ A, B, C
/home/user/snapshot/ <empty>

Modified state (option a):

/home/user/ A, B, C'
/home/user/snapshot/ A, B, C

or is it rather (option b):

/home/user/ A, B, C'
/home/user/snapshot/ C

Smart snapshots always show you the entire (sub)volume and it is up to the user to diff the changes between the snapshot he's looking at and the current state or earlier/later snapshots. Hence I wondered if custom snapshots "[X] with changes only" refers to when a snapshot is taken or also to what it contains (only the changed content or the entire volume).

Greets,

Volker

[StephenB]

"Smart" snapshots will be made every hour, even if the share contents haven't changed. Custom Snapshots with  "Only take snapshots with changes"  will only be made if something has changed.  So if the share hasn't changed, the snapshot will be skipped. Since most of my shares aren't changed that often, this is much more convenient.

All snapshots show you the complete share as it existed when the snapshot was made.  There is a way to see only the changes if you use ssh, but Netgear hasn't built it into the web ui.  If you want to research that, it's the btrfs send command with the --no-data flag.  It's much faster than using diff.

---

@VolkerB wrote:
where all unchanged file(s) and directory/-ies point to the same location (a hard link probably) and only the changed file(s) and directory/-ies get a new link.

Not a hard link, but not the worst conceptual starting point.  More like hard links on steroids.  Snapshots are a BTRFS feature, that are built on the copy-on-write feature of the file system.

When a snapshot is taken, the files in the snapshot and the main share are all shared data blocks.   "Copy on write" means that when something in the main share is modified, the change will be written to new blocks.  The original blocks are now only used by the snapshots, the modified blocks are used only by the main share (until another snapshot is taken). 

This is not done at the file level (so not a hard link).  It is done at the block level.  If one block in a very large file is changed (w/o rewriting the entire file), then the file in the main share becomes fragmented (since it is still sharing all but one block with the snapshots).  Defragging the share will rewrite the entire file in the main share (which will increase the total space used by the share, since none of the file blocks will be shared by the snapshots anymore).

The CoW feature can also be used to advantage when copying files, by adding --reflink to the SSH cp command.  When you copy a folder with --reflink, the copy takes no additional on-disk space.  You can then modify the original, without modifying the copy - so again, not a hard link.  You can even use --reflink when copying to another share (subvolumes). 

FWIW, "bit rot protection" is a combination of features.  CoW is one (it can be enabled/disabled with BTRFS).  Another is BTRFS block checksums, and the third is a proprietary Netgear feature.  The feature uses a combination of RAID parity blocks, and block checksums to try and recover any data that suffered bitrot (silently changed on the disk).  I wish that Netgear hadn't combined all three features into one checkbox, but I guess they thought it would be simpler.

Snapshots of course require CoW.  But if bit rot protection is turned off, the NAS is supposed to turn CoW on in order to make the snapshot (and then turn off CoW again afterwards).  Similarly, a ReadyNAS "push" back job (local source) makes a snapshot before the backup starts, and then backs up the snapshot.  When the job completes, the snapshot is destroyed.  That makes the backup coherent.

[VolkerB]

@StephenB wrote:

"Smart" snapshots will be made every hour, even if the share contents haven't changed. Custom Snapshots with  "Only take snapshots with changes"  will only be made if something has changed. [...] All snapshots show you the complete share as it existed when the snapshot was made.[...] Snapshots are a BTRFS feature, that are built on the copy-on-write feature of the file system. [...] When a snapshot is taken, the files in the snapshot and the main share are all shared data blocks.   "Copy on write" means that when something in the main share is modified, the change will be written to new blocks.  The original blocks are now only used by the snapshots, the modified blocks are used only by the main share (until another snapshot is taken).

 Ah, OK. Thanks for explaining. So if snapshots are reflecting the diff on a block level, you might even get away with quite some benefit if there is just something added to a huge file - depending on the block size of course.

---

@StephenB wrote:

This is not done at the file level (so not a hard link).  It is done at the block level.  If one block in a very large file is changed (w/o rewriting the entire file), then the file in the main share becomes fragmented (since it is still sharing all but one block with the snapshots).  Defragging the share will rewrite the entire file in the main share (which will increase the total space used by the share, since none of the file blocks will be shared by the snapshots anymore).

Understood. So it was actually a good idea that I ran a defrag before reenabling snapshots on my box.

---

@StephenB wrote:

The CoW feature can also be used to advantage when copying files, by adding --reflink to the SSH cp command.  When you copy a folder with --reflink, the copy takes no additional on-disk space. You can then modify the original, without modifying the copy - so again, not a hard link.  You can even use --reflink when copying to another share (subvolumes). 

Quite convenient - especially for large amounts of data The "copy" (which is then just some work in an allocation table) will then probably happen in an instant.

---

@StephenB wrote:

FWIW, "bit rot protection" is a combination of features.  CoW is one (it can be enabled/disabled with BTRFS).  Another is BTRFS block checksums, and the third is a proprietary Netgear feature.  The feature uses a combination of RAID parity blocks, and block checksums to try and recover any data that suffered bitrot (silently changed on the disk).  I wish that Netgear hadn't combined all three features into one checkbox, but I guess they thought it would be simpler.

Snapshots of course require CoW.  But if bit rot protection is turned off, the NAS is supposed to turn CoW on in order to make the snapshot (and then turn off CoW again afterwards).

---

According to my findings in this post BTRFS is/was turned on in all (sub)volumes of the home share, so I obviously just forgot to turn on [X] Protection option in the Home Folders > Settings > Snapshot Access for all the users where snapshots should be taken and all is good. I'll do a couple of tests to verify this, your tip with the BTRFS send command and the --no-data option for sure will be helpful. But I don't expect any irregularities there, since the NAS was using "protection" for the new test user by default and snapshots immediately worked. A warning dialog would have saved me quite some time (Hey, Netgear developers!) but whatever...

Finally I need to point out that I don't run my RN214 24/7 - for various reasons.

Firstly, it is rather a convenience option that I switch on if it is necessary to access my big archive of raw video, audio and image files, i. e. if I need to do some video and/or image editing. On my PC, I just have 128GB of local storage for the OS and another 500GB for "data", both on Samsung SSD. I don't see a need to spend big $$$ on massive capacity there - if I need to work on a project, I either copy over a portion temporarily or even work directly on the NAS. With link aggregation and two Seagate IronWolf, it's not that slow.

Secondly I also switch on the RN214 whenever it's time for syncing the PC with network storage (robocopy on the Windows machine and rsync on Ubuntu), which is not fully scripted yet (e. g. I could do Wake-on-LAN and also boot the PC automatically) or backup to USB3-drives that I connect to the NAS (local rsync job attached to the backup button) in a rotating schedule. So chances are quite high that at least a couple files are always different (think email database, files in /home/user, etc.) whenever I run the sync, so it doesn't matter much whether I take "smart" or "custom" snapshots. I like the retention/promotion feature of smart snapshots but that for sure is a matter of personal preferences.

It's a bit of a pain though to create a decent snapshot schedule if the NAS is off most of the time. So I told it to boot every Saturday at 0:00AM and do weekly snapshots (they are supposed to be taken Friday at Midnight and the last one promoted to a monthly snapshot at the end of the month, see this article). Only to find out that no snapshots were taken at all and you rather need to boot the machine one hour earlier (Friday 11PM) and let it run for two hours. That is no big problem since spun down disks are woken up for weekly snapshots but still feels a bit unnecessary. "Custom" snapshots are no exception to that.

And I would love the NAS to stay in/revert to it's original power state in case there is a power loss. So: If it has been off, it should stay off if the power comes back and vice versa. Every PC has a BIOS option to control that (and the RN214 probably has as well), but the BIOS is inaccessible - at least from my knowledge level. As it is configured right now, it always turns on if power comes back which requires an unnecessary power schedule entry (e. g. at midnight) if you don't want to have it running for days and days if you come back from a couple days of vacation or a business trip.

OK, that is probably lamenting on the highest level now. I have to say that I'm quite happy with the RN214, in terms of reliability, build quality (took it apart recently to clean the fan) and feature richness. It took quite some investigation to arrive at this Netgear product and in comparison the cheaper devices from QNap and Synology just stink. That I had to preform a factory reset after a backup gone wrong and the volume filled up to the brim is a bit disappointing but probably my own fault. I should have watched more carefully if the job was indeed cancelled or not.

So: Thanks again for your support, for sure I again have learned something. And probably other users wanting to find out about BTRFS, snapshots and user's home (sub)volume as well. Have a nice day!

Volker

[StephenB]

---

@VolkerB wrote:

And I would love the NAS to stay in/revert to it's original power state in case there is a power loss. So: If it has been off, it should stay off if the power comes back and vice versa. Every PC has a BIOS option to control that (and the RN214 probably has as well), but the BIOS is inaccessible - at least from my knowledge level. As it is configured right now, it always turns on if power comes back which requires an unnecessary power schedule entry (e. g. at midnight) if you don't want to have it running for days and days if you come back from a couple days of vacation or a business trip.

I have several ReadyNAS, the main one is on 24/7 (with spindown enabled), the backups are on a power schedule. 

I wish it had an option there as well.  FWIW, connecting the NAS to a UPS will solve this, as the NAS then won't see a power loss when the power fails.  It also protects against unclean shutdowns (which can result in an out-of-sync RAID array).

---

It's a bit of a pain though to create a decent snapshot schedule if the NAS is off most of the time. So I told it to boot every Saturday at 0:00AM and do weekly snapshots (they are supposed to be taken Friday at Midnight and the last one promoted to a monthly snapshot at the end of the month, see this article). Only to find out that no snapshots were taken at all and you rather need to boot the machine one hour earlier (Friday 11PM) and let it run for two hours. That is no big problem since spun down disks are woken up for weekly snapshots but still feels a bit unnecessary. "Custom" snapshots are no exception to that.

Yeah, I power up the backups at 11 pm.  No big problem, but a bit annoying to have that constraint.

If you use the scheduled maintenance (disk test, balance, volume scrub, defrag), then you'll also find that some of those tasks will be terminated when the shutdown time arrives (instead of holding off shutdown until the task completes).  I've modified one of the Netgear scripts to change that behavior.  I also modified the cron schedule for those tasks (for example, to run on the first Friday of the month if the NAS is powered up on Fridays).