Issues out of nowhere

[evilbunny]

What is the best way to "backup" the SD card image periodically?

Depends what you plan to backup to, I have a r64 running a personal website, and I use rsnapshot on another SBC to make incremental daily backups.

[fsa317]

I have home assistant running with some local scripts and an influxdb running on my P64.

I have a separate ubuntu system that has a really large hard drive with some free space.   To do what you described, do I run rsnapshot on the P64 or on the "other" system?  I'm assuming I can run it on the P64 but have the output snapshot go to shared folder on the other system?

Any advice is really appreciated as I want to try to get this right.

[pfeerick]

Hm, handy to know... that a corrupt filesystem can trigger media failure like messages... who would have thunk it?

You can do it either way... either have a share on your ubuntu box that you access on your pine64 box when you run rsnapshot on it, or you have a share on the pine64 that you access from your ubuntu box and you run rsnapshot on the ubuntu box. If the pine64 is on all the time, and the ubuntu box infrequent, I'd suggest have the share on the pine64 so you can have a fstab entry on the ubuntu box that automatically mounts it if present on boot, and then have a cron task that preiodically does the snapshot.

Just keep in mind the rsnapshot is more for data files... you won't be able to make a bootable backup media that way. If that is your intent (i.e. a save point so if the card really does fail you can just image a new one and pick up from that already configured point) I just use dd (i.e. dd if=/dev/<microsd> of=/home/<username>/<image-name> bs=1MB progress=status) and pipe the output to pxz to compress it so I have a compressed backup of the entire microSD if there is a particular one I want to preserve.

[evilbunny]

I have a separate ubuntu system that has a really large hard drive with some free space.   To do what you described, do I run rsnapshot on the P64 or on the "other" system?  I'm assuming I can run it on the P64 but have the output snapshot go to shared folder on the other system?

You install rsync on your P64, and rsync and rsnapshot on your ubuntu system if they aren't installed already. You need ssh keys as well so you can connect to the P64 as root and without a password.

Then you just need to configure rsnapshot, below is a basic config file, tweak as needed and save it as /etc/rsnapshot.conf. Using it will keep 12 monthly backups, 4 weekly backups and 7 daily backups. You could do hourly but I find that is usually over kill for most setups.

Code:

config_version  1.2

cmd_cp          /bin/cp
cmd_rm          /bin/rm
cmd_rsync       /usr/bin/rsync
cmd_ssh         /usr/bin/ssh
cmd_logger      /usr/bin/logger
cmd_du          /usr/bin/du

interval        daily   7
interval        weekly  4
interval        monthly 12

verbose         1
loglevel        3
logfile /var/log/rsnapshot.log

rsync_short_args        -ADlpRrtz
rsync_long_args         --numeric-ids --delete-during --delete-excluded
lockfile        /var/run/rsnapshot.pid

snapshot_root   /path/to/save/rsnapshot/backups/

backup  root@192.168.x.x:/etc/                 192.168.x.x/
backup  root@192.168.x.x:/home/                192.168.x.x/
backup  root@192.168.x.x:/root/                192.168.x.x/
backup  root@192.168.x.x:/usr/                 192.168.x.x/
backup  root@192.168.x.x:/var/                 192.168.x.x/

You can then do a test run, rsnapshot -V -t -c /etc/rsnapshot.conf daily

This will tell you if ssh is working and output files it would have copied

Then you just need to edit /etc/crontab

Code:

0  22   * * *   root    /usr/bin/rsnapshot -V -c /etc/rsnapshot.conf daily
30 21   * * 7   root    /usr/bin/rsnapshot -V -c /etc/rsnapshot.conf weekly
0  21   1 * *   root    /usr/bin/rsnapshot -V -c /etc/rsnapshot.conf monthly

I like reports, but if you only want errors remove -V from the commands.

The above only copies /etc /home /root /usr and /var, you may not need to copy all of those, or you may wish to include more directories, it really depends on your setup. Basically you only need to backup what you have changed or data that gets saved and so on, and when you do a fresh install most libraries and binaries will already exist.

---

Just keep in mind the rsnapshot is more for data files... you won't be able to make a bootable backup media that way. If that is your intent (i.e. a save point so if the card really does fail you can just image a new one and pick up from that already configured point) I just use dd (i.e. dd if=/dev/<microsd> of=/home/<username>/<image-name> bs=1MB progress=status) and pipe the output to pxz to compress it so I have a compressed backup of the entire microSD if there is a particular one I want to preserve.

rsnapshot allows you to take near live backups, rather than taking the P64 offline to clone, and rsnapshot can happen automatically, so you don't have to remember to do anything.

Also rsnapshot only backs up changed files, with an image you also backup empty space as well as duplicating all the libraries and binaries, regardless if they change or not.

It all depends on your specific situation, and preferences.

[fsa317]

Hm, handy to know... that a corrupt filesystem can trigger media failure like messages... who would have thunk it?

You can do it either way... either have a share on your ubuntu box that you access on your pine64 box when you run rsnapshot on it, or you have a share on the pine64 that you access from your ubuntu box and you run rsnapshot on the ubuntu box. If the pine64 is on all the time, and the ubuntu box infrequent, I'd suggest have the share on the pine64 so you can have a fstab entry on the ubuntu box that automatically mounts it if present on boot, and then have a cron task that preiodically does the snapshot.

Just keep in mind the rsnapshot is more for data files... you won't be able to make a bootable backup media that way. If that is your intent (i.e. a save point so if the card really does fail you can just image a new one and pick up from that already configured point) I just use dd (i.e. dd if=/dev/<microsd> of=/home/<username>/<image-name> bs=1MB progress=status) and pipe the output to pxz to compress it so I have a compressed backup of the entire microSD if there is a particular one I want to preserve.

Thanks, yea I want it as more of a full restore.  So in theory using dd I could make the of= point to a network mounted drive so I always have a restore image.  Will dd work on the microsd card if its actively mounted?

[evilbunny]

Thanks, yea I want it as more of a full restore.  So in theory using dd I could make the of= point to a network mounted drive so I always have a restore image.  Will dd work on the microsd card if its actively mounted?

You could if it is mounted read-only...

[pfeerick]

Thanks, yea I want it as more of a full restore.  So in theory using dd I could make the of= point to a network mounted drive so I always have a restore image.  Will dd work on the microsd card if its actively mounted?

@fsa317: Yes, but as evilbunny said, if mounted read-only. However, imaging a live system is a good recipe for disaster when you try to restore from it...

I personally would do a blend... Spin up a new image, do the bulk of your configuration and then image it. That's your full reasonably clean backup base image and a bootable restore point. Then use rsnapshot to do the incremental and differential backups of data files. Then when the time comes, you can either restore from that backup image, and then pull across the backups from rsnapshot, or you can use a completely different base image, and pull the data across still. Best of both worlds.

@evilbunny: Yeah, hence why tried to pointed out rsnapshot was for data files, not bootable media I fully agree though, it's the better option for automated data backups. There's always zerofree if you're picky about empty space, but pxz seems to do a good job so far of squishing the images of even SBCs that have been running for a couple of years...