Learn Samba - Recycle Bin & Shadow Copies

#Introduction

A deleted file isn't just a panicking user's problem — it's also part of the operational risk that design must anticipate. In episode 12 we install two layers of protection: a recycle bin for light deletion mistakes, and shadow copies (snapshots) for deeper version recovery. Together they form the "safety net" that lets you sleep well: a lost file can almost always be brought back.

#VFS Recycle: A Trash Bin in Samba

#Concept

The recycle VFS module changes deletion behavior: a file deleted by a client isn't really gone — it's moved to a special directory inside the share (e.g. .recycle). It's analogous to the Windows Recycle Bin, but runs server-side, protecting all clients at once.

[data]
   path = /srv/data
   vfs objects = recycle
   recycle:repository = .recycle
   recycle:keeptree = yes
   recycle:versions = yes
   recycle:exclude = *.tmp, ~$*

Breaking down the options:

• recycle:repository = .recycle: the folder where deleted files are stored (relative to path).
• recycle:keeptree = yes: preserve the original folder structure — easy to browse and restore.
• recycle:versions = yes: if a filename already exists in recycle, add a timestamp — no file gets overwritten.
• recycle:exclude = *.tmp, ~$*: don't recycle junk files (temp and Office locks) — they're useless in the recycle bin and only waste space.

#How to Restore

Because recycle only moves files, recovery is done by an admin server-side:

sudo ls /srv/data/.recycle/
sudo mv "/srv/data/.recycle/documents/laporan.q3.xlsx" /srv/data/documents/

You can also view the recycle contents from a client (the .recycle folder appears as a share), but best practice is to give restore access to admins only — "deleted" files shouldn't be readable by just anyone. Set .recycle permissions at the filesystem level so only admins can enter (episode 4: the filesystem layer).

#Shadow Copy: Snapshot and "Previous Versions"

#The Snapshot Concept

A snapshot is a read-only image of the filesystem at a point in time — you can take one every hour and use it to restore a file as it was. On Linux, snapshots are made at the filesystem level: Btrfs (subvolume snapshots) or LVM (logical volume snapshots).

#Making a Btrfs Snapshot

sudo btrfs subvolume snapshot -r /srv/data /srv/data/.snapshots/@GMT-2026.08.13-12.00.00

#Making an LVM Snapshot

sudo lvcreate -L 10G -s -n snap-data /dev/vg0/data
sudo mkdir -p /mnt/snap-data
sudo mount -o ro /dev/vg0/snap-data /mnt/snap-data

LVM snapshots are used by mounting them at a point Samba can read, while Btrfs places snapshots inside the filesystem tree itself. The naming pattern matters: use the @GMT-YYYY.MM.DD-HH.MM.SS format — this is what Windows recognizes as Previous Versions.

#Connecting to Samba: shadow_copy2

[data]
   path = /srv/data
   vfs objects = shadow_copy2
   shadow:snapdir = .snapshots
   shadow:format = @GMT-%Y.%m.%d-%H.%M.%S
   shadow:localtime = yes

• vfs objects = shadow_copy2: expose snapshots as "previous versions" to SMB2+ clients.
• shadow:snapdir = .snapshots: for Btrfs, the folder where snapshots are stored.
• shadow:format = @GMT-%Y.%m.%d-%H.%M.%S: the name pattern mapped to the version list — must match the snapshot naming exactly.
• shadow:localtime = yes: interpret times in the server's local timezone.

For LVM, the snapshot format doesn't follow a free name pattern; use an empty shadow:snapdir and name LVM snapshots per the @GMT-... pattern at lvcreate time (via a cron script), then schedule their mounts.

#Using Previous Versions on Windows

In Explorer, right-click a file/folder → Properties → Previous Versions — you'll see the list of available snapshots and can restore or copy an older version. This is the feature that lets users recover files themselves without calling IT — a huge operational win.

#Automation and Maintenance

#Cron for Routine Snapshots

0 * * * * btrfs subvolume snapshot -r /srv/data \
  /srv/data/.snapshots/@GMT-$(date +%Y.%m.%d-%H.%M.%S)

#Retention Policy

Snapshots consume space — without retention, a full disk is the end of the story. Btrfs: remove snapshots older than N days with a script. LVM: limit snapshot size (lvcreate -s -L) — a full LVM snapshot "breaks" and becomes unusable. A rule of thumb: retention of 7-14 days, frequency matched to data churn, and always monitor disk usage (episode 20).

#Common Pitfalls

• Previous Versions empty: the shadow:format pattern doesn't match the snapshot names — make them identical.
• Snapshots fill the disk: no retention — install a policy for deleting old snapshots.
• Recycle folder accessible to users: lock .recycle at the filesystem level so only admins can enter.
• LVM snapshot "breaks" suddenly: the snapshot filled up — limit its size and monitor lvs.

#Closing

Key takeaways:

• vfs objects = recycle moves deleted files to .recycle with keeptree and versions options.
• Btrfs/LVM snapshots are the foundation of shadow copy; the @GMT-... name format must be consistent.
• shadow_copy2 exposes snapshots as Previous Versions in Windows.
• Recycle isn't backup — it's the first layer, not the only one.
• Snapshot retention must be configured, or a full disk becomes the next problem.

In episode 13 next, we'll cover firewall & network security — the Samba ports (139, 445, 389/636, 135/137/138), firewall policies with ufw/firewalld, and the golden rule: never expose SMB to the internet, use a VPN/WireGuard. Network security starts to take over!